WordPress Click2Shell: core RCE chain patched in 7.1.1, but themes extend exposure

The disclosure

On September 21, 2026, researchers disclosed an attack chain nicknamed Click2Shell: an unauthenticated remote code execution path in WordPress Core that was subsequently fixed in WordPress 7.1.1 through changeset 63664. According to a dev.to analysis of the event, SecurityOnline.info carried the original report together with a proof of concept, drawing on a technical write-up from pwn.ai. At the time of the analysis, no CVE had been assigned and the researchers had observed no exploitation in the wild.

How the chain works

The attack runs in two stages, as laid out in the dev.to write-up. First, a crafted link causes the browser of a logged-in administrator to install a theme from the catalog automatically, the result of a theme-slug parser discrepancy in core. Second, the installed theme exposes an unprotected AJAX handler that fetches attacker-supplied PHP from a remote package and executes it on the server.

The chain carries what the analysis calls an authentication-shaped gate: no attacker-side WordPress credentials are ever required, but no code executes until an administrator visits the attacker-chosen URL. That makes it a social-engineering-assisted chain rather than an open door, and it shapes which sites are genuinely at risk — in practice, nearly any site where an administrator might plausibly click a link.

Two layers to patch

The exposure surface splits into a core layer and a theme layer:

• Core: the parser discrepancy affects every WordPress version before 7.1.1. Upgrading to 7.1.1 or later closes the forced-installation stage.
• Theme: the second stage abuses unprotected AJAX endpoints in catalog themes, with Mobile Repair Zone 2.5.4 and more than 40 other themes identified. A site running patched core but holding a vulnerable theme — even an inactive one — still carries the second-stage code if an attacker can get that theme loaded during a Customizer preview.

What the 7.9 million number counts

One day after the disclosure, a ZoomEye query for app="WordPress" (executed 2026-09-22 UTC) returned 7,945,496 matching assets. The dev.to author's central point is that headline figures like this invite two opposite errors: dismissing the incident as noise, or treating every matched host as breached. Both readings are wrong. The count reflects indexed product assets, not vulnerable patch levels and certainly not successful attacks.

The product fingerprint answers only "where is WordPress", which is the outer boundary of the problem. It cannot say which of those instances run a vulnerable theme, because themes are not part of what the fingerprint captures.

How teams should use the figure

For teams using ZoomEye during the event, the analysis recommends treating the query as a scoping and prioritization tool: locating WordPress assets in a network range, comparing counts before and after cleanup, and flagging assets that reappear after being decommissioned. Observations should be recorded alongside the exact query, timestamp and total, and any report built on them should repeat the caveat that indexed assets are not confirmed vulnerable hosts and that an exposure count is not a breach count.

Why it matters

WordPress's install base makes any core-level RCE path a serious incident, and Click2Shell reaches code execution from a single administrator click — a gate that is weaker in practice than it sounds, since administrators follow links all the time. Remediation is also two-layered: patching core is necessary but not sufficient while vulnerable catalog themes remain installed, including ones that are not actively used. Finally, the episode is a lesson in reading scan data during a security event. A 7.9 million figure is useful for scoping, but presenting it as a count of vulnerable or compromised hosts misstates both the attack's preconditions and the actual work required to close the gap.