Security1 publisher2 min readPublished
Click2Shell runs attacker PHP on WordPress servers after a single administrator click
Paulos Yibelo of pwn.ai reported the Core flaw on August 22 and WordPress fixed it in 7.1.1 last week. The full proof-of-concept is now public, and the chain needs no attacker account, only an administrator who opens a link.
The Watch · Security desk
What happened
- Click2Shell is a pre-authenticated remote code execution chain in WordPress Core that installs any theme from the official WordPress.org catalog and runs an arbitrary PHP file on the server.
- Paulos Yibelo of the autonomous penetration testing platform pwn.ai found the flaw and reported it to WordPress on August 22.
- The attacker does not authenticate, but the exploit only fires when a logged-in administrator visits the crafted URL, which is the single precondition on the victim side.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Any site still on 7.1.0 or earlier is reachable through its administrators' inboxes, and the attacker needs nothing on the target to start.
- capability An admin-facing XSS bug in any plugin or theme becomes a server-side code execution path on unpatched Core, because the administrator's browser sends the request without a click.
- decision Operators who cannot upgrade this week have one named blocker, DISALLOW_FILE_MODS, and enabling it is a configuration change that has to be in place before the phishing mail arrives.
- contradiction The pre-authenticated label describes the attacker's requirements; the trigger still sits in an authenticated administrator's browser, so a site with two careful admins is a harder target than the label implies.
The chain turns on one value read twice. pwn.ai's researchers wrote that "a value from a WordPress theme-preview URL is interpreted once by the WordPress.org Themes API and a second, buggy methods by JavaScript in the Administrator's browser" [6]. The result is a theme added to the target site without the administrator choosing to install it [7]. The second stage does not need activation: an inactive theme still executes PHP while the Customizer builds a preview [8].
WordPress closed it in 7.1.1 by escaping the theme slug before using it in the jQuery selector, and by restricting that selector to actual theme cards [18]. The defect sat in the dashboard's own JavaScript [22].
The attacker works the chain without an account, an installation nonce, or privileges of their own [10]. The chain needs an administrator with a live session who opens the crafted URL [9]. Patchstack, which analysed the flaw, says Author and Editor accounts cannot trigger it because they lack permission to install themes [16], and warns the request can equally be produced by targeted phishing or by an existing XSS flaw that makes the administrator's browser send it [17].
Once PHP runs, the reachable set includes file modification and deletion, user data, and wp-config.php with its database credentials and authentication secrets [13]. From there come rogue admin accounts and injected scripts [14]. The Core defect is in 7.1.0 and earlier [15], so every install not running 7.1.1 is in scope [20].
pwn.ai demonstrated the chain using one vulnerable theme from the catalog as the second component [11], and the report says the Core flaw could be used to force-install any other vulnerable theme in that catalog [15]. Version 7.1.1 blocks the forced install, and it does not change the themes themselves, which an administrator can still install by hand [21]. For sites that cannot upgrade at once, Patchstack says a site with DISALLOW_FILE_MODS enabled cannot be forced into installing the theme or a malicious plugin [19].
Yibelo reported the flaw on August 22 [5]. The fix shipped last week, and the issue has no official identifier [3][2]. Technical details and a working exploit are public [1], so the usual gap between a patch and usable exploit code is already gone. The published report carries a complete proof-of-concept for server-side remote code execution [12].
What to watch
- Whether an official identifier is assigned, since scanners and patch-compliance tooling key on one.
- Whether the vulnerable catalog theme used as the second stage, and others like it, are patched or pulled from WordPress.org.
- First reports of the chain fired against live admin sessions, and whether delivery is phishing or stored XSS in a plugin.