Click2Shell Turns a WordPress Admin Visit Into a Forced Theme Installation
WordPress patched Click2Shell flaw letting attackers trick admins into installing themes, chainable to RCE. Update to 7.1.1 now.
Text generated by artificial intelligence, published without human review. AI transparency
Illustrative image generated with AI
A newly patched WordPress core vulnerability allows an attacker to make an authenticated administrator’s browser install and preview a chosen theme from the official WordPress.org directory. Researchers at pwn.ai named the resulting technique Click2Shell.
The core flaw is rated high severity, with a CVSS score of 7.1. It does not directly permit arbitrary file uploads or code execution. However, the researchers demonstrated that combining it with a separate flaw in a WordPress theme can produce server-side code execution, raising the full chain’s score to a critical 9.6.
WordPress fixed the issue in version 7.1.1, released on September 17, and distributed corresponding security updates for supported branches going back to WordPress 4.7. There is currently no evidence that attackers have exploited Click2Shell in the wild.
A malicious URL makes WordPress click its own Install control
Click2Shell exploits inconsistent processing of the same attacker-controlled URL value by the WordPress.org theme directory and JavaScript running in the administrator’s browser.
The theme directory treats the supplied value as a conventional theme name and returns a legitimate theme hosted on WordPress.org. Browser-side code subsequently reuses the value, including punctuation added by the attacker, to identify an element in the page.
That manipulation causes the code to select the theme’s Install control. WordPress’s own JavaScript then triggers the control without requiring the administrator to click the installation button manually.
The browser supplies everything needed to authorize the action because the victim is already signed in with administrator privileges. This includes the authenticated WordPress session and the security token used to approve installation. The attacker therefore does not need to steal credentials, predict the token, or authenticate directly to the site.
There is still a user-interaction requirement. The target must be logged in as an administrator and must open the specially constructed link.
This condition limits the attack compared with a fully unauthenticated remote exploit, but it also makes the URL suitable for phishing, direct messages, support-themed lures, or other methods intended to reach site administrators.
An inactive theme can still expose executable PHP
The forced installation does not activate the chosen theme. Consequently, the public website retains its existing design, and administrators may see no immediate visual indication that another theme has appeared on the server.
Inactive does not mean inert, however.
WordPress can load and execute PHP belonging to an inactive theme when producing a preview through the Customizer. Click2Shell takes advantage of that behavior: after forcing installation, the attack moves into preview processing, where vulnerable theme code can become reachable without changing the site’s normal active theme.
The distinction defines the vulnerability’s practical impact. The WordPress core issue installs a genuine theme selected by the attacker from the official directory. It cannot, by itself, upload an arbitrary theme ZIP or introduce attacker-written PHP directly.
To achieve server-side code execution, the selected theme must contain another exploitable weakness. Click2Shell provides a route for placing that theme on the target and causing WordPress to process its code.
Mobile Repair Zone completed the proof-of-concept chain
For their demonstration, pwn.ai researchers selected the Mobile Repair Zone theme. A vulnerable background handler in that theme accepted a web address from a request, downloaded a package from the specified location, and executed code from the package.
The handler did not verify whether the requester had the required permissions. It also failed to require a security token.
Those missing controls made the handler useful as the second stage of the attack. First, Click2Shell caused WordPress to install Mobile Repair Zone from WordPress.org. WordPress then loaded the inactive theme while generating a Customizer preview. Once its vulnerable handler was available, the attacker could direct it to retrieve and execute attacker-controlled code on the server.
This is a chained exploit rather than a standalone remote-code-execution bug in WordPress core. The two components have separate roles:
- Click2Shell abuses an administrator’s session to install and preview a legitimate theme.
- The theme vulnerability retrieves a remote package and executes its contents without adequate authorization checks.
The critical 9.6 rating applies to this complete path. The core installation flaw alone carries the 7.1 score.
WordPress 6.0 through pre-fix releases are affected
The vulnerability has been confirmed in WordPress 6.0 and later releases up to the versions immediately preceding the correction. The primary fixed release is WordPress 7.1.1.
WordPress also issued equivalent security updates for applicable supported branches, with release coverage extending back to version 4.7. Administrators do not necessarily need to move every installation to the 7.1 feature branch, but they must apply the matching security release for the branch they operate.
Sites configured to accept automatic WordPress core security updates should receive the correction automatically. Operators should still verify the installed version rather than assume that an update completed successfully, particularly where file permissions, deployment controls, or update-management settings can interrupt automated installation.
WordPress has not published its own severity classification for Click2Shell. No CVE identifier has been assigned at this time, although pwn.ai said WordPress plans to add one.
No public indicators of compromise have been provided. The affected URL format and other detection artifacts are also not known from the available disclosure.
Updating core closes the forced-installation path
Administrators should install WordPress 7.1.1 or the corresponding security update for their existing supported branch. Updating core blocks the demonstrated installation and preview technique regardless of whether Mobile Repair Zone or another potentially vulnerable theme is present.
Neither WordPress nor pwn.ai has supplied a separate technical workaround for systems that cannot be patched immediately. Until an update is applied, administrators should avoid opening untrusted links while signed in to WordPress, especially URLs presented as site-management, theme, or support resources.
That precaution only reduces exposure. It does not remove the vulnerable behavior.
Defenders can also review installed themes for unexpected additions, including themes that remain inactive. Because Click2Shell does not need to activate its selected theme, monitoring only changes to the active theme would miss the behavior demonstrated by the researchers. An unexplained theme installation should prompt examination of administrator activity and subsequent Customizer processing.
Click2Shell is not the same as wp2shell
Click2Shell follows another WordPress core issue found by pwn.ai and fixed in August. That earlier vulnerability concerned the login screen and could also be combined with other weaknesses to reach code execution, although WordPress described its risk more narrowly than the researchers.
A different WordPress core vulnerability disclosed in July, called wp2shell, is unrelated to pwn.ai’s Click2Shell work. Its exploitation conditions are more severe: wp2shell requires neither authentication nor a victim click, and CISA has listed it as exploited in real-world attacks.
Click2Shell has no equivalent evidence of active exploitation. Its reliance on an authenticated administrator opening a malicious URL creates a meaningful prerequisite, but the proof of concept shows how that single action can cross several security boundaries—from browser-side element selection to theme installation, preview-time PHP loading, and ultimately server-side execution when a second vulnerable component is available.
Sources
This article is an original reworking based on the sources below.
