WordPress 7.1.1 blocks a crafted link that makes an admin's browser install the attacker's theme

Two parts of WordPress read the same link differently. The WordPress.org directory treats the value in the URL as an ordinary theme name and hands back a real theme, while the administrator's browser reuses the original text, punctuation and all, inside code meant to pick out one item on the page; the characters the attacker adds point that code at the Install button, and WordPress's own script clicks it ^[8]. Because the administrator is already logged in, their session supplies the permission and the security token the install needs, so the attacker supplies neither ^[9].

What lands is a real theme from the directory, and it stays switched off, so nothing about the site's appearance changes ^[10]. "The Core bug does not accept an arbitrary theme ZIP by itself," pwn.ai wrote ^[7]. Reaching code execution took a second flaw in the theme that was installed. Mobile Repair Zone had a background handler that pulled a web address out of the request, downloaded a package and ran its code, with no permission check and no token ^[12].

Switched off is not inert. WordPress's Customizer can load a theme's PHP while building a preview, before anyone activates the theme ^[11]. That makes every dormant theme on a site code the site can still run. It is not, however, what the demonstrated chain depended on: the core bug installs the theme the attacker names, so the vulnerable pairing arrives with the attack ^[2][12]. Updating core closes the demonstrated path whatever themes a site keeps ^[16].

pwn.ai scored the forced install alone at 7.1 and the full chain at 9.6 ^[4]. The 2.5-point gap between them comes from one third-party theme's missing permission check ^[20][12]. WordPress did not publish a severity rating of its own, and in its release described the issue as "Specially crafted URLs can automatically install and preview an inactive theme from WordPress.org" ^[5][6]. The split repeated an August case, when WordPress fixed another pwn.ai bug in the login screen that the researchers also chained to code execution and described the risk more narrowly than they did ^[18].

The chain needs a logged-in administrator to open the attacker's link, and there is no sign of use in real attacks ^[16][17]. The July core flaw called wp2shell, which is unconnected to pwn.ai's work, needs neither a login nor a click, and CISA has listed it as exploited ^[19].

The security release backports fixes to supported branches as far back as 4.7, the notes confirm the flaw from 6.0 up to the releases just before the fix, and sites set to update automatically will take it on their own ^[14][15]. Neither WordPress nor pwn.ai offered a workaround, and no CVE identifier has been assigned yet, though pwn.ai says WordPress plans to add one ^[16][13].