WordPress patched the flaw in version 7.1.1. Reaching full code execution required a second, separate bug in a specific theme — this wasn't exploitable through Core alone.
What happened
On September 17, 2026, WordPress shipped WordPress 7.1.1, a maintenance and security release bundling 11 fixes.[1] One line item stood out: a bug that let specially crafted URLs automatically install and preview an inactive theme from WordPress.org.[1] The security firm that found it, pwn.ai, named the issue Click2Shell.[2]
On its own, that's an odd but fairly contained bug: a logged-in administrator who opens a booby-trapped link ends up with a theme installed they never asked for. The theme stays inactive, so the site doesn't visibly change. Not exactly a five-alarm fire.
The interesting part is what pwn.ai did next. They went looking for a way to turn "attacker picks a theme and it gets installed" into something more dangerous, and found it: a separate flaw in a specific WordPress.org theme, Mobile Repair Zone,[3] that let its preview code run attacker-supplied PHP once the forced install had placed it on disk. Chain the two together and, per pwn.ai's writeup, one link opened in an administrator's browser was enough to get code running on the server.[2]
Why "no CVE yet" matters here
There's no CVE identifier for this issue as of publication. pwn.ai says WordPress has told them one is coming.[2] I'm not assigning one or guessing at a number — if you see one reported elsewhere, treat it as unverified until it shows up on CVE.org or WordPress's own advisory.
How the forced install actually works
I'm deliberately not walking through the exact injection technique, request format, or proof-of-concept code here — pwn.ai's writeup includes working exploit scripts, and reproducing that level of detail in a news article just hands out a recipe. What's safe and useful to know:
WordPress's theme installer reads a value from the URL in two different places that don't agree with each other. One side treats it as a plain theme name and looks it up against the official WordPress.org catalog. The other side — JavaScript running in the administrator's browser — reused that value in a way that let an attacker manipulate which on-page button got clicked. The practical effect: WordPress's own script ended up clicking its own "Install" button, using the session and permissions the logged-in administrator already had. pwn.ai's technical writeup covers the mechanism in full if you're auditing your own theme code.[2]
That step alone only installs a theme that genuinely exists in the WordPress.org catalog — it can't push an arbitrary attacker-hosted ZIP file.[2] It's a forced-install bug, not a direct code-execution bug.
Why an inactive theme still matters
The part that made this chainable is easy to miss: an installed-but-inactive theme isn't necessarily dormant. WordPress can load a theme's PHP while building a Customizer preview, even while a completely different theme is the one actually active on the site.[2] That's the bridge pwn.ai used — they went looking for a theme whose preview-time code did something unsafe with that access, and found one in the Mobile Repair Zone theme, then current at version 2.5.4.[2] pwn.ai says over 40 third-party catalog themes had a similar class of issue.[2]
That distinction matters for how you read this bug. The Core flaw made an installation happen without consent. It did not, by itself, hand an attacker the ability to run code — that required a bug in the theme that got installed. If your site never has a vulnerable theme reachable through the catalog, the code-execution half of this chain doesn't apply to you, even if the forced-install half does.
Severity and exploitation status
pwn.ai rated the standalone forced-install flaw as High, CVSS 3.1 score 7.1, and rated the complete chain to code execution as Critical, CVSS 3.1 score 9.3, with a user-interaction requirement lowering the impact score.[2] WordPress has not published its own severity rating; its release notes describe the issue narrowly, without a CVSS figure of their own.[1] The Hacker News reported a slightly different pair of figures from pwn.ai's own public statements — 7.1 for the forced-install flaw and 9.6 for the full chain[3] — so there's a discrepancy between pwn.ai's blog post and what they told reporters; I've flagged both rather than picking one.
On exploitation: there is no evidence of active, in-the-wild exploitation of Click2Shell. The Hacker News explicitly noted no sign of real-world attacks,[3] and pwn.ai's own timeline shows this as a coordinated disclosure — reported privately in August, fixed in September, publicly detailed only after the patch shipped.[2] That's a meaningfully different situation from a vulnerability under active attack, and it shouldn't be described as one.
It's also worth being precise about what this attack requires: a logged-in WordPress administrator has to open a specific crafted link. It isn't unauthenticated, and it isn't a drive-by that works against any visitor. That's a real limiting factor, even for the full chain.
Who's affected
pwn.ai's advisory describes the Core issue as affecting all WordPress versions before 7.1.1.[2] The Hacker News reports that the fix reaches supported branches back to 4.7, per WordPress's own release documentation.[3] The code-execution half of the chain only applies to sites where the specific vulnerable theme (or one with a similar flaw) is installable and reachable — not to every WordPress site running an affected Core version.
What defenders should do
- Update to WordPress 7.1.1 or the matching security release for your branch.[1] Sites with automatic background updates enabled should already have it.
- Neither WordPress nor pwn.ai published a workaround for sites that can't update immediately — updating is the fix.[3]
- If you're a theme developer, the underlying lesson is the more durable one: don't assume an inactive theme's code never runs. Customizer previews can execute theme PHP before activation, so any AJAX handler or file-processing code in your theme needs its own nonce and capability checks — it can't rely on the theme being "off."
Security takeaway
Click2Shell is a good example of how a fairly minor-looking bug — a forced but otherwise harmless theme install — becomes a critical one only when paired with an unrelated weakness somewhere else in the ecosystem. WordPress Core wasn't directly exploitable for code execution here; a specific theme's shortcuts were. If you run WordPress, patching Core closes the forced-install path no matter what theme you use, which is the useful, durable fix regardless of how the severity numbers eventually settle.
Sources & References
- [1] WordPress.org — WordPress 7.1.1 Maintenance and Security Release — September 17, 2026.
- [2] pwn.ai — Click2Shell: Preauth WordPress Core Theme Preview Injection to RCE Chain — September 18, 2026.
- [3] The Hacker News — New WordPress Click2Shell Flaw Forces Theme Installs, Can Chain to Code Execution — Swati Khandelwal, September 18, 2026.
Disclaimer: No CVE identifier had been assigned to this issue at the time of publication. This article will be updated if one is issued.
Technical Discussion & Feedback
Leave a Comment (Authenticated Users)