Critical WordPress Core Flaw Lets Hackers Run Code Remotely

A severe vulnerability in WordPress core allows unauthenticated attackers to execute arbitrary code on any affected site — no plugins required. WordPress has already shipped emergency patches for versions 6.9.5 and 7.0.2.

No Login Required: The Anatomy of a Bare-Core WordPress Exploit

A critical security vulnerability discovered in WordPress core has sent administrators scrambling to update their installations after researchers revealed that a completely stock WordPress site — one with no plugins, no themes beyond the default, and no additional configuration — could be compromised by anyone capable of sending a standard HTTP request. The flaw, tracked under the name wp2shell, was discovered by Adam Kues, a researcher at Assetnote, the attack surface management arm of Searchlight Cyber, and responsibly disclosed to the WordPress security team.

What makes this vulnerability particularly alarming is the absence of any prerequisite for exploitation. Many high-severity web flaws require at least some level of authentication — a subscriber-level account, a valid session token, or a specific plugin to be installed. wp2shell requires none of that. An anonymous HTTP request is sufficient to trigger remote code execution on a vulnerable host, which places millions of websites at immediate theoretical risk.

Scope: Every 6.9 and 7.0 Installation Was Vulnerable

WordPress powers roughly 43 percent of all websites on the internet, making the blast radius of any core-level vulnerability genuinely enormous. According to the disclosure, every site running WordPress 6.9 or 7.0 was within range of this attack until patches were released late last week. WordPress responded by shipping versions 6.9.5 and 7.0.2 and simultaneously activating its forced auto-update mechanism — a system designed to push critical security fixes to sites even when administrators have not manually enabled automatic updates.

The use of forced updates is relatively uncommon and signals how seriously the WordPress security team assessed the threat. In past incidents, WordPress has reserved this mechanism for only the most severe vulnerabilities, understanding that overriding administrator preferences is a disruptive measure justified only when the alternative — leaving millions of sites exposed — is far worse.

What Attackers Could Actually Do

Remote code execution vulnerabilities are considered the most severe class of security flaw in web applications. When successfully exploited, an attacker gains the ability to run arbitrary commands on the underlying server. In a WordPress context, this could mean extracting database credentials, exfiltrating user data including email addresses and hashed passwords, injecting malicious content into pages, deploying backdoors for persistent access, or using the compromised server as a launchpad for further attacks on internal networks or other web properties.

Because the vulnerability exists in core rather than in a third-party plugin or theme, there is no optional component to disable as a temporary mitigation. The only reliable remediation is patching to the fixed versions.

What Site Owners Should Do Right Now

For the vast majority of WordPress site owners, the auto-update mechanism should have already applied the patch automatically. However, administrators who have disabled auto-updates — a common practice on heavily customized or enterprise-grade deployments — must manually update to 6.9.5 or 7.0.2 immediately. Site owners should also review their server logs for anomalous unauthenticated POST requests in the period preceding the patch, as indicators of compromise may be present on sites that were targeted before the fix became available.

Hosting providers and managed WordPress platforms have also been quietly patching at the infrastructure level, and several major hosts confirmed emergency rollouts over the weekend.

A Sobering Reminder About Core Trust

The wp2shell disclosure is a sobering illustration of a risk that is easy to overlook: the assumption that a default, plugin-free installation is inherently safe. The security conversation around WordPress has long focused on the ecosystem of third-party extensions, where the sheer volume of plugins creates a vast and frequently unpatched attack surface. A core vulnerability of this severity shifts that narrative. It suggests that even organizations running lean, minimal WordPress deployments cannot treat the platform itself as a trusted base. The speed of WordPress’s response — patches and forced updates within the disclosure window — is commendable, but the incident underscores that no layer of a web stack, however foundational, is immune to critical flaws.