WordPress Comment2Shell: Anonymous Comment XSS Can Chain Into Server RCE on Unpatched Sites
WordPress Comment2Shell: Anonymous Comment XSS Can Chain Into Server RCE on Unpatched Sites
WordPress site owners who haven't installed version 7.1.1 face a newly documented attack chain in which an anonymous visitor leaves a comment that plants a hidden script on the page — and if a logged-in administrator later opens that page, the script can use the admin's own session to run code on the site's server. The flaw, tracked as CVE-2026-93485 and dubbed Comment2Shell, was fixed in WordPress 7.1.1 on September 17, the same security release that patched the Click2Shell link-attack chain. Rafie Muhammad, the researcher who reported the bug, published the full working chain on September 21. He says he is not aware of the flaw being used in attacks, and it is not on the U.S. government's list of actively exploited software flaws.
The bug sits in the gap between two moments: WordPress checks a comment for dangerous HTML when it is saved, then reformats it when the page is shown. The trick is a line break placed inside the attribute of an allowed HTML tag in the comment. When WordPress reformats the comment for display, one of its steps breaks that tag apart and moves the attacker's text into a position where the browser treats it as a live event handler. The handler runs automatically as the page loads — no click required — and it executes in the browser of whoever opens the page, acting with that person's access level to the site.
From Comment to Web Shell
Running code on the server needs one more condition: a logged-in administrator has to open the page carrying the comment. The script can then use the administrator's own session to upload a plugin containing a web shell — a small file that executes whatever commands an attacker sends. Uploading a plugin through an admin session is a known route from an administrator's browser to control of the server, and Muhammad confirmed the full chain working end to end.
The attack depends on how a site displays its comments. It works on sites that use a block theme — and every default WordPress theme since Twenty Twenty-Two is one. On a site with a classic theme, it only works on posts or pages that contain comment blocks. WordPress describes the flaw as exploitable only "subject to comment approval," but comment moderation is off by default, and the setting that holds a first-time commenter can be worked around, so a comment can reach the page without anyone approving it. As Patchstack, which rated the flaw 7.1 on the CVSS scale, put it: "moderation isn't a security control."
What Should You Do?
- Update to WordPress 7.1.1 — or to the fixed release for your branch: 7.0.5 for the 7.0 line, 6.9.8 for 6.9, and the branch releases going back to 4.7.36. Affected versions span 4.7 through 7.1.
- If you cannot update right away, close comments — on the affected posts or across the site. That shuts the entry door while you schedule the upgrade.
- Let a WAF or security plugin block the crafted comment. A web application firewall can catch the malicious pattern before it is ever saved to the database.
- Audit for attacker leftovers. Updating fixes the flaw, but it does not undo changes an attacker already made — sites with reason to believe they were targeted should look for plugins and files they do not recognize.
The WAF Angle
Comment2Shell is a validation-gap bug, and it rhymes with a class WAFNinja has covered for years: the same input is judged safe at save time and dangerous at render time, and the attack lives in the difference. WordPress core has had a rough year — wp2shell in July ran code with no login at all and later landed on the actively exploited list, an August flaw in the login page executed code as an administrator, and Click2Shell chained a crafted link into a theme install. Two practical takeaways for defenders: first, a WAF that inspects comment POST bodies stops this chain at its first link — confirm your rules actually cover comment submissions, which some CDN and WAF configurations skip. Second, the pivot from stored XSS to plugin upload runs through an admin session, so treat "install plugin or theme" actions that follow a page view as high-signal events worth alerting on.
