When a vulnerability affects WordPress core rather than a third-party plugin, it hits differently. The wp2shell flaw discovered by Adam Kues at Assetnote demonstrates exactly why: an attacker needs no account, no special configuration, and no add-ons to achieve remote code execution. A bare WordPress installation running versions 6.9 or 7.0 was vulnerable out of the box.
The Scope of Exposure
Core vulnerabilities are a particular concern for hosting providers because they affect customers across the board—not just those running outdated or poorly-maintained plugins. WordPress 6.9 and 7.0 were current releases at the time of discovery, meaning newly deployed sites using standard installation methods fell into the vulnerable range. The unauthenticated nature of the attack vector is what elevates the risk profile considerably. An attacker required no credentials, no CSRF token, and no knowledge of site-specific configuration to exploit it.
WordPress responded by shipping patches in versions 6.9.5 and 7.0.2 on Friday, and more importantly, by forcing automatic updates through its background auto-update system. The forced update approach is significant: it bypasses the typical WordPress update flow where site administrators can delay patches, and instead pushes the fix out immediately to most installations. For hosting providers managing shared or managed WordPress environments, this automatic enforcement removes a common friction point in security updates.
Why Core Flaws Require Different Handling
Plugin vulnerabilities are common and well-understood in the WordPress ecosystem. Hosting teams monitor feeds, test updates in staging, and typically wait a day or two before rolling them out. Core vulnerabilities demand urgency. An attacker does not need to know which plugins a target is running, does not need to guess at version numbers through fingerprinting, and does not need to wait for a site owner to upgrade—they can attempt the exploit against any WordPress installation and have a statistical chance of success until the patch is applied.
The fact that a bare install is exploitable also eliminates a common excuse for delay. Sites cannot be 'hardened by simplicity' or protected by minimal configuration. Even a fresh WordPress download with the default set of core files presents an attack surface.
Implications for Hosting Operators
For providers running managed WordPress hosting or reseller environments, the auto-update enforcement is both a relief and a reminder. Relief, because it means most affected sites will patch without manual intervention. A reminder, because it underscores the importance of monitoring core update status even when auto-updates are enabled—not all installations have them active, and some site owners may have disabled the feature for deployment reasons.
Proactive providers should verify that their WordPress instances are running at least 6.9.5 or 7.0.2 (or newer minor versions). For customers on older major branches—5.x or early 6.x releases—the flaw does not apply, but these sites should still be on a supported track. Any site running 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1 requires immediate patching.
From an infrastructure perspective, this incident also highlights the value of immutable or containerised WordPress deployments. If a hosting platform deploys WordPress via container images with pinned versions, updates can be rolled out at the infrastructure layer rather than relying on site-level auto-update mechanisms. That approach removes ambiguity and ensures consistency across a fleet.
A Broader Pattern
Core vulnerabilities in major CMS platforms tend to receive rapid response and forced patches precisely because they affect everyone equally. WordPress has demonstrated this pattern before. The challenge for hosting operators is ensuring that their customer communication, monitoring dashboards, and update scheduling reflect this urgency. A plugin CVE might warrant a 48-hour staging window; a core RCE should move within hours.
The wp2shell flaw is now patched and the auto-update system has pushed the fix to the vast majority of affected sites. For sysadmins managing self-hosted WordPress instances or smaller platforms, the lesson remains straightforward: monitor core releases closely, test patches in a staging environment, and deploy them on the same day or within 24 hours. For those managing customer-facing WordPress platforms, ensuring auto-updates are enabled by default and cannot be easily disabled is a reasonable baseline security policy.
