Click2Shell Turns Admin Clicks Into Theme Installs

A logged-in WordPress administrator who opens the wrong link may never notice anything changed. According to research published by the security firm pwn.ai, a crafted URL can cause WordPress to install a theme from the official directory on its own — no Install button press required — and the same chain can be extended to run attacker-controlled code on the server.

WordPress shipped a fix for the flaw, and a set of related core issues, in its 7.1.1 security release. The company's guidance is the usual one for a security update: apply it now. There is no indication so far that the flaw has been used in real-world attacks.

How a Link Becomes an Install

The core of the bug is a disagreement between two parts of WordPress about what a link means. When the attack URL points at the WordPress.org theme directory, the directory reads the value in that URL as a plain theme name and hands back a real theme. The administrator's browser, meanwhile, carries the original text of the link — punctuation and all — into a piece of code meant to locate an element on the page.

Extra characters an attacker appends to the link steer that lookup to the Install button. WordPress's own script then performs the click. Because the administrator is already authenticated, their session supplies both the permission and the security token the install requires. The attacker provides neither.

As pwn.ai wrote of the core bug in isolation, "The Core bug does not accept an arbitrary theme ZIP by itself." In other words, the forced install is limited to themes that already exist in the official directory — it cannot push an attacker's own package onto the site. pwn.ai calls the attack chain Click2Shell.

The Theme Stays Switched Off

An installed theme does not necessarily sit idle. The research team found that when WordPress builds a preview inside its Customizer tool, it can load a theme's PHP code even before that theme is activated. That preview path is what gives an otherwise dormant theme a chance to run.

The absence of a visible change is part of what makes the core flaw hard to spot. The theme that gets installed remains deactivated, so the site's own appearance does not change. Visitors see the same design, and nothing in the site's front end looks wrong.

From Silent Install to Code Execution

Reaching code execution required a second, separate weakness — one that lived in the theme itself rather than in WordPress core. The theme pwn.ai used in its demonstration, Mobile Repair Zone, carried a background handler that fetched a web address from the incoming request, downloaded a package, and executed its code. The handler performed no check on the visitor's permission and required no security token.

Chained after the forced install, that handler ran the attacker's code on the server. The two flaws are distinct: the core bug supplied the install, and the theme's handler supplied the execution. Neither half of the chain does the full job alone, which is why pwn.ai's write-up separates the core issue from the theme issue.

Severity Ratings and the CVE Question

• CVSS 7.1 — pwn.ai's rating for the forced-install flaw on its own, which it classes as high severity.
• CVSS 9.6 — the researchers' rating for the full chain to code execution, which they class as critical.
• September 17 — the date the fix shipped in WordPress 7.1.1.
• Version 4.7 — the oldest supported branch reached by the security release's fixes.
• Versions 6.0 and up — the range in which WordPress's notes confirm the flaw, through the releases just before the fix.

WordPress has not published a severity rating of its own. In the release, the project described the issue this way: "Specially crafted URLs can automatically install and preview an inactive theme from WordPress.org." That wording is narrower than pwn.ai's, focusing on the install and preview behavior rather than the chain to code execution. No CVE identifier has been assigned yet, though pwn.ai says WordPress plans to add one.

A Pattern in Recent WordPress Core Bugs

Click2Shell is not the first WordPress core flaw pwn.ai has reported in recent weeks. In August, WordPress fixed a similar flaw that pwn.ai found in the login screen and also chained to code execution. In that case too, WordPress described the risk more narrowly than the researchers did — a recurring gap between how a vendor frames a bug's impact and how the reporting team characterizes it.

A different WordPress core flaw disclosed in July, called wp2shell, is not connected to pwn.ai's work. The two differ in a way that matters for defenders: wp2shell requires no login and no click, and the U.S. cybersecurity agency CISA has listed it as exploited in real attacks. Click2Shell has not been listed as exploited, and it still depends on an administrator opening the attacker's link while logged in.

Who Is Exposed

The flaw's reach depends on the version a site runs. WordPress's release notes confirm the issue from version 6.0 up through the releases immediately before the fix, and the security release as a whole extends fixes back to the 4.7 branch. Sites on supported branches have a matching update available.

The demonstrated chain also depends on the specific theme. The forced install only pulls a theme that already exists in the WordPress.org directory, and the code execution step required Mobile Repair Zone's unguarded background handler. That means the chain pwn.ai showed is tied to that theme's behavior, not to a capability the core bug confers on any theme a site might have installed.

What Site Owners Should Do

WordPress's guidance is to install 7.1.1, the security release, or the matching update for whichever branch a site runs. Sites configured to update automatically will receive the fix on their own.

Neither WordPress nor pwn.ai offered a separate workaround for site owners who cannot update immediately. The release notes frame the fix as a core update rather than something addressable by configuration. Updating WordPress core closes the demonstrated attack regardless of which theme a site happens to run.

The remaining exposure, for sites that cannot patch right away, is the requirement that a logged-in administrator open the attacker's link. The chain does not fire on its own, and it does not target anonymous visitors or unauthenticated sessions.

Why This One Matters Beyond the Patch

The immediate practical takeaway is the update itself, but the chain is worth understanding because of what it says about where WordPress risk has been concentrating. Two of the three recent core flaws in this account — the August login-screen bug and now Click2Shell — came from pwn.ai, and both were escalated past their initial classification by chaining a core issue to a second weakness elsewhere in the stack. A vulnerability that looks like a nuisance in isolation, such as a forced theme install with no visible effect, can become a server compromise when it is paired with a theme that mishandles requests.

That suggests defenders should treat vendor severity language and researcher severity ratings as complementary rather than interchangeable. WordPress's own description of Click2Shell covers the install and preview behavior; pwn.ai's 9.6 covers the full chain. For a site owner deciding how urgently to patch, the higher number is the one that reflects what the researchers actually demonstrated. The gap between the two descriptions is not an accusation of bad faith — it reflects a real difference in scope between a core bug and a chain built on top of it.

The theme layer is the less visible half of that lesson. The forced install is bounded by what exists in the official directory, but the execution step came from a theme's request handler trusting input it should not have trusted. Sites that run many themes, or that keep unused themes installed, carry a larger surface for exactly that kind of chained escalation, even though this particular demonstration involved a single theme.

Finally, the contrast with wp2shell is the clearest signal in the record. wp2shell needs no login and no click and has been listed by CISA as exploited in real attacks. Click2Shell needs both a logged-in administrator and a click on a crafted link, and it has not been listed as exploited. The two sit at different points on the exploitation spectrum, and the difference is a reminder that "no known exploitation" describes the present, not the flaw's potential.

— Reporting based on original coverage from The Hacker News.