A visitor with no account on your site could leave a comment, and if you opened the page while logged in as an administrator, that comment could quietly install a web shell on your server. That’s the practical effect of a WordPress core flaw researcher Rafie Muhammad disclosed on September 21, 2026, and WordPress had already patched four days earlier without most site owners noticing the fix was for something this severe.
Table of Contents
The bug is tracked as CVE-2026-93485 and goes by the name Comment2Shell. Patchstack, which assigned the identifier, rated it 7.1 out of 10 on the CVSS scale, high but not the top-tier critical rating some other 2026 WordPress core bugs have carried. WordPress fixed it in version 7.1.1, released September 17, alongside ten other security issues in the same update. It’s worth noting up front: as of the disclosure, there’s no sign it was used in real attacks, and it isn’t on the U.S. government’s Known Exploited Vulnerabilities list. This is a patch-now situation, not a five-alarm one. One caution: detailed write-ups and proof-of-concept exploit code have since circulated publicly, which usually shortens the time before real attacks begin.
Comment2Shell: How an anonymous comment turns into an admin-session hijack
WordPress checks a comment for dangerous HTML when it’s saved, then reformats it again when the page displays it. Comment2Shell lived in the gap between those two steps. Muhammad’s write-up describes the trick: a line break placed inside an HTML tag attribute in the comment text. When WordPress’s wpautop() function reformatted the comment for display, that line break caused the tag to be split apart in a way that moved the attacker’s text into a position the browser read as a live event handler, code that executes automatically.
The handler fired the moment the page loaded, with no click or interaction required from whoever viewed it. If an ordinary visitor loaded the page, the script ran with that visitor’s browser access, which is limited. The real danger showed up if a logged-in administrator opened the same page. At that point, the script could use the administrator’s own active session to upload a plugin, one built to function as a web shell, a small file that lets an attacker run arbitrary commands on the server from then on.
Using an admin’s browser session to install a plugin is a well-understood route from a client-side script to full server control, and it’s the same escalation pattern that makes stored XSS bugs in admin-facing software worth treating seriously even when the initial bug looks minor.
Why comment moderation didn’t save most sites
WordPress’s own advisory describes the flaw as exploitable ‘subject to comment approval,’ and by default a first-time commenter’s post is held for moderation before it appears publicly. That sounds like a built-in safety net. Muhammad’s research found ways around that check, letting a crafted comment reach the page without an administrator ever clicking approve. Patchstack’s own summary of the bug put it bluntly: moderation isn’t a security control. Treating comment approval as your actual defense against this class of bug was never a safe assumption, and this flaw is a concrete example of why.
The attack also required a specific display path. It worked against sites running a block theme, which has been WordPress’s default since Twenty Twenty-Two, meaning it covers a large share of sites built or redesigned in the last several years. Some classic (pre-block) themes were affected too, where they format comments through the same code path; Muhammad’s write-up specifically names Twenty Twenty-One as one example. Sites on older classic themes that never touch that formatting step were not exposed through this particular mechanism.
What’s actually patched, and what to update to
The fix landed in WordPress 7.1.1. Affected versions run from 4.7 through 7.1.0. Here’s what to update to depending on your branch:
| Branch you run | Update to |
|---|---|
| 7.1 | 7.1.1 |
| 7.0 | 7.0.5 |
| 6.9 | 6.9.8 |
Older branches, back to 4.7, have their own fixed releases as far back as 4.7.36, listed in WordPress’s release documentation. If you already updated to WordPress 7.1.1 for any reason since September 17, you’re covered against this specific flaw; it’s only sites still sitting on 7.1.0 or earlier that remain exposed.
Neither WordPress nor Muhammad published a dedicated workaround beyond updating, which is the recommended fix. If you genuinely can’t update your core files immediately, say you’re waiting on a plugin compatibility check, two partial mitigations reduce exposure without closing the hole entirely: close comments on individual posts, or turn comments off site-wide until you can patch. A web application firewall or a comment-focused security plugin may also catch and block the specific crafted pattern, though that’s a filter, not a fix for the underlying code.
If you think a comment already got through
Updating stops the flaw going forward; it doesn’t undo anything an attacker already did before you patched. If your site runs a block theme, has open comments, and you have any reason to suspect it may have been targeted before September 17, check your plugin list for anything you don’t recognize installing, and review your comments (including ones still in moderation or spam) for entries containing unusual HTML attributes or line breaks inside tags rather than plain text.
A web shell dropped through this route typically shows up as a newly installed plugin with a generic or misleading name, not obvious malware, so a quick scan of your installed-plugins screen for anything you didn’t add yourself is a reasonable five-minute check even if nothing seems wrong.
Why this kind of bug keeps showing up
Comment2Shell is one of several WordPress core flaws disclosed in September 2026 that relies on an administrator’s own session rather than a direct server exploit, following Click2Shell in the same release. That’s not a coincidence so much as where attackers have shifted their attention: WordPress core has gotten harder to compromise directly over the years, so bugs that trick a privileged user’s browser into doing the damage for them have become the more reliable route in. It also means the usual advice, run fewer plugins, keep core updated, only covers half the actual attack surface.
The other half is admin hygiene: log out of wp-admin when you’re not actively using it, avoid browsing the public-facing side of your own site in the same browser tab where you’re logged into the dashboard, and if your site takes comments from the public at any real volume, treat comment moderation as a workflow tool rather than a security boundary, since Comment2Shell is a direct demonstration of what happens when it’s asked to be both.
The broader pattern this fits
WordPress 7.1.1 patched 11 security issues in total, and Comment2Shell was the only one reachable by a completely unauthenticated attacker; most of the others needed a logged-in user with some existing access first. The same release also fixed a second bug called Click2Shell, where a crafted link could trick WordPress into installing a theme and chaining that into code execution, again requiring an administrator to open the link. Both bugs share a theme: neither one is a dramatic, unauthenticated hack-the-server-directly flaw.
Both rely on tricking a logged-in administrator’s own session into doing the damage, which is exactly why keeping the number of people with admin access small, and making sure every one of them is running an up-to-date browser and isn’t in the habit of opening unreviewed content while logged in, matters as much as the software patch itself.
For site owners managing this across more than one WordPress install, whether that’s an agency handling client sites or a business running separate sites for different brands, this is the kind of release where an update strategy that doesn’t depend on someone remembering to log in and click Update Now earns its cost. AllCloudHost’s WordPress hosting applies core security releases like 7.1.1 without waiting on a manual login, which matters most on exactly this kind of bug: the ones that sit quietly for days before anyone notices they were serious.
Further reading: WordPress.org: security news.