WordPress Just Had Its Biggest Vulnerability Ever. Here's What It Means for Campus IT.

In July, security researchers found a serious bug in WordPress. People are calling it WP2Shell. Josh Koenig, co-founder of the WebOps hosting company Pantheon, said it best in a recent interview with EdTech Connect: "This is the most serious WordPress security update ever."

He's not exaggerating. On most WordPress sites, this bug lets an attacker take over the whole site without even logging in. No password needed. That's about as bad as a bug can get, and it was sitting inside WordPress itself, not some random plugin.

Here's what happened, why colleges got hit harder than most.

What Happened

The vulnerabilities got built into WordPress back in December, when a new version shipped. Researchers found and reported the problem on July 17, and WordPress released a fix within days. Sites with auto-update turned on got the fix pushed to them automatically.

The way researchers found this bug is its own story. One of them, Adam Kues, said no person could have pieced this together alone. It took running the same test over and over, watching for one tiny crack in how WordPress checks requests. That's the kind of repetitive work AI tools are good at. This won't be the last bug AI helps find.

Once the fix was public, the clock started. Josh says the gap between the fix going live and attackers weaponizing it was only about 6 to 8 hours. Sites that auto-updated closed the door in time. Sites that had auto-update turned off, often because an update once broke something, stayed open, and there were a lot of them. This bug touched hundreds of millions of installs.

Attackers weren't picking targets carefully, either. Pantheon even saw scan traffic hit its Drupal sites, which don't run WordPress at all. Bots were just poking every website they could find.

Why Colleges Got Hit Harder

Every industry runs some WordPress. Higher ed's setup makes this kind of bug especially hard to contain.

Most colleges don't have one person in charge of "WordPress." There's a central web team, plus a dozen department sites, plus research centers running their own, plus old faculty pages nobody remembers setting up. Auto-updates aren't turned on everywhere, because a central team can't risk breaking someone else's site. And a lot of these sites sit on the same shared servers, so one hacked department page can become a doorway into everything else on that server.

The risk isn't spread evenly, though. Josh's take is that the schools in the most trouble are the ones running dozens or hundreds of WordPress sites on some general, informal hosting setup, with no real way to push a fix in six to eight hours. A single old Linux server running a department's WordPress site is a real danger. If WordPress was out of date, the server underneath it probably was too. Now there's a fully hacked computer sitting inside the campus network. From there, attackers usually do something boring: mine cryptocurrency, or use that machine to go look for the next one.

Oddly, the sites furthest from campus IT, like a professor's own GoDaddy account, can be less dangerous even though they're just as easy to hack. They're a pain to clean up, but they weren't plugged into anything else worth breaking into, thought you might be hit with a surprise bill if an attacker turned the underlying compute infrastructure into a bitcoin mining operation.

The biggest exposure sits with schools that still run WordPress hosting as a do-it-yourself service for departments, with no one watching what's running and no fast way to patch it.

What Managed Hosting Actually Buys You

This is where "WordPress" and "how WordPress is run" stop being the same question.

On Pantheon, the live site is “immutable.” It can't edit itself. Any code change has to go through a review process first, so the part of this attack that writes new files onto the server had nowhere to land. Pantheon can also push emergency rules across every site on its platform at once to block exploit attempts at the network layer. While this shield isn’t a guarantee, it can offer more “defense in depth” for teams that need more time to roll out patches. 

That's the real question to ask any hosting company. Not whether they run open-source software, but whether one bug can turn into full control of a site, and whether they can push an emergency fix to every site at once. Good hosting turns "did we patch every site in time" into a non-issue. Bad hosting turns it into a fire drill.

Don't Blame Open Source

It's easy to look at all this and think WordPress, or open source in general, is uniquely risky. The facts don't back that up.

WordPress itself has a solid security record. The bad reputation WordPress carries in some circles comes mostly from its huge pile of plugins, some of which are poorly built, and from how loosely a lot of WordPress sites get maintained. The core software isn't the problem. And this kind of AI-powered bug hunting isn't a WordPress problem, either. It's turning up bugs across all kinds of software right now, including paid software whose code you never see.

Take SolarWinds. That's probably the biggest software hack ever, and it hit paid, closed software used to manage other companies' Microsoft systems.

Commercial software isn't safer.

Companies just don't have to tell you when it gets hacked. The real lesson here is about knowing what's running on your systems and who's watching it. A fake admin account gets created when nobody's tracking what changes on a site. That gap exists no matter what software sits underneath it. Managed hosting makes tracking that stuff mandatory. Running things yourself — or with a partner that doesn’t enforce tracking of code — means your safety net is only as good as whatever the software maker tells you, and how fast your team can move when it counts.

What This Means for Your Campus

The incident is a good reality check to find out where all your school's WordPress sites live, who's in charge of updating each one, and whether your setup, managed or not, can push a fix in hours instead of days.

If your school runs WordPress sites as a casual, do-it-yourself service across shared servers, with no one clearly in charge and no fast way to patch, that's the problem to fix. Not the software. The way it's run.\

---

EdTech Connect covers the tools and infrastructure decisions shaping higher ed technology. Subscribe to The Signal for more conversations like this one with the people building and securing the platforms your campus runs on.