WordPress 7.1.1 fixes 'Click2Shell' CSRF chain with public exploit

Researchers have published technical details and a working proof-of-concept for a cross-site request forgery flaw in WordPress Core, named Click2Shell. According to the original report, it allows an unauthenticated attacker to force the installation of any theme from the WordPress.org catalogue and have PHP run on the server — provided a logged-in administrator opens a crafted link. WordPress addressed the issue in version 7.1.1 last week.

What happened

The flaw was found by Paulos Yibelo of pwn.ai and reported to WordPress on 22 August. It has no official CVE identifier at the time of the report. The root cause is a value from a theme-preview URL that is handled one way by the WordPress.org Themes API and a different, buggy way by JavaScript running in the administrator's browser.

The practical effect is a chain. The attacker does not need an account, administrative rights, or an installation nonce. But the request has to come from an administrator's browser, so the entry point is a crafted link — targeted phishing, or an existing cross-site scripting flaw on the site that makes the browser issue the request on its own. Once the theme is added, its PHP can execute during a Customizer preview even while the theme is inactive.

The demonstration used one specific vulnerable theme as the second stage, but the report states the Core flaw in 7.1.0 and earlier could be used to force-install other vulnerable themes from the catalogue. Server-side code execution here means access to files, user data and wp-config.php with database credentials and authentication secrets, plus the usual follow-ups: rogue administrator accounts and injected scripts. WordPress fixed it by escaping the theme slug before it reaches the jQuery selector and limiting the selector to real theme cards. Patchstack, which analysed the chain, notes that Author and Editor accounts cannot trigger it because they lack theme installation rights.

Why it matters

Many small and medium companies run their public site, and often a customer portal or shop, on WordPress that nobody looks at between releases. Two details make this one worth your attention now: the exploit is public in full, and the trigger is a single click by an administrator — the same people most likely to click a link that looks like a support ticket or a plugin notice. Shared hosting and sites where marketing holds admin accounts are the weak spots.

What to do

• Update every WordPress installation you own to 7.1.1, including staging, archived microsites and client sites you maintain. Inventory first; forgotten installs are the usual casualties.
• Where an update cannot happen today, set DISALLOW_FILE_MODS in wp-config.php. Patchstack notes that sites with it enabled cannot be forced into installing the theme or a plugin. Treat it as a stopgap.
• Reduce the number of accounts with the administrator role, and require phishing-resistant MFA on the ones that remain. Editors and authors cannot trigger this chain.
• If a site was running 7.1.0 or earlier and is publicly exposed, check for unexpected themes, new admin users and recent changes under wp-content before you close the ticket.