A Critical WordPress Vulnerability Just Made the Case for Web Maintenance Plans

Every website is like a car. It runs great off the lot, but the road takes its toll. Tires wear down. Fluids need topping off. Warning lights come on, and if you ignore them, small problems become expensive ones.

WordPress just handed the entire internet a reminder of exactly that, in the form of a vulnerability called wp2shell.

What Happened

In mid-July, security researchers disclosed a critical flaw in WordPress core, tracked as CVE-2026-63030 and CVE-2026-60137. Together, the two vulnerabilities became known as wp2shell, and the name says it all. By chaining a flaw in WordPress’s REST API with a SQL injection vulnerability, an attacker could take over a vulnerable site with a single request. No login. No plugin required. No user interaction. Just a default WordPress install and a bad actor who knew where to look.

Within days, proof-of-concept exploits were circulating publicly, and security firms confirmed active exploitation in the wild. Sites were compromised, admin accounts were created without consent, and webshells were planted to keep the door open for future access. WordPress responded fast, shipping emergency patches, but the window between disclosure and exploitation was measured in hours, not weeks.

This is the reality of running on the world’s most popular CMS. It’s powerful, flexible, and widely trusted, and that popularity makes it a constant target. When a flaw like this surfaces, the sites left unpatched aren’t an afterthought. They’re the plan.

It’s worth being clear that this isn’t a WordPress problem specifically. Any content management system, whether it’s WordPress, Drupal, Webflow, or a custom-built platform, runs on code that gets updated, patched, and occasionally found to have a flaw nobody caught until it was too late. The platform changes. The pattern doesn’t. Software needs upkeep, and the sites that stay ahead of that are the ones a vulnerability like this never touches.

What Push10 Did

As soon as this vulnerability came to light, our team got to work. We identified every site under an active Push10 maintenance plan running an affected version of WordPress, applied the patch, and confirmed each one was clear. No waiting for a scheduled check-in. No hoping an auto-update quietly did its job in the background. Our team verified it, site by site.

That’s the part that doesn’t show up in a headline. A vulnerability like this doesn’t care how good your website looks or how well your brand tells its story. It cares whether someone patched the software before an attacker found it. For our maintenance clients, that work was already underway before most site owners even knew there was a problem.

Why This Matters Beyond This One Vulnerability

This will not be the last vulnerability of its kind, and wp2shell certainly isn’t the first, on WordPress or any other platform. Every CMS ships core software, plugins, and themes that are updated constantly, and every update is both a fix and a signal to attackers about what was broken. Sites that don’t stay current become easier targets, not harder ones, the longer they go unpatched, regardless of what platform they’re built on.

This is exactly why Push10 built ongoing maintenance into how we support clients after launch. A website isn’t a project with a finish line. It’s a living asset that needs consistent attention: monitoring, updates, backups, and someone watching for the moment something like wp2shell shows up. Push10 offers a range of maintenance plans built around these needs, scaled to fit different levels of support, so clients have a team ready to respond the moment it matters, not after.

If a critical vulnerability broke tomorrow, would you know if your site was affected? Would someone already be working on it? That question is the entire argument for why maintenance isn’t a nice-to-have. It’s the seatbelt you don’t think about until you need it.