WordPress patched a core vulnerability on September 17 that turns something as mundane as a blog comment into a path to full server compromise. Researchers are calling it Comment2Shell, tracked as CVE-2026-93485 with a CVSS score of 7.1, and it affects every WordPress core release from 4.7 through 7.1, which covers the overwhelming majority of WordPress sites running today. No authentication is required to fire the first stage. An attacker only needs a comment box that accepts input, which on most WordPress sites means anyone with a browser.
How a comment turns into a shell
The bug doesn’t live in the comment form’s input filtering, it lives one step later, in how WordPress reformats a comment for display. An attacker submits a comment containing a line break placed inside an HTML tag attribute, something the initial sanitization pass doesn’t catch because at submission time the payload still looks harmless. The problem shows up when WordPress reformats that comment for the page: the line break splits the tag structure apart and effectively repositions the attacker’s text into what the browser now reads as an event handler.
The result is a script that fires automatically the moment the page loads, running with whatever access level belongs to the person viewing it. For a regular visitor, that’s nothing interesting. For a logged-in site administrator who happens to open the page the comment lives on, most commonly a moderation screen or the post itself, the script executes in their authenticated session. From there it can install a plugin carrying a web shell, and a web shell on a WordPress site means arbitrary command execution on the server underneath it.
Why “just enable comment moderation” doesn’t save you here
The instinctive fix most site owners reach for is comment moderation: hold every comment for approval before it goes live. It helps, but researchers are explicit that moderation is not a security control in this case, and the reasoning is straightforward. WordPress ships with moderation off by default, so a large share of sites never turn it on in the first place. And even where it is enabled, the payload only needs to render once in front of a logged-in administrator, and the moderation queue itself is a page an administrator looks at, logged in, specifically to review pending comments. The exact workflow meant to catch spam is also the exact workflow that puts the payload in front of the one account that matters.
The flaw isn’t specific to one theme or plugin either. Researchers found it triggers on both block themes and classic themes that use comparable comment-formatting logic, which is most of them, since that formatting logic lives in WordPress core rather than in individual themes.
What’s patched and what isn’t
WordPress fixed the issue across every actively maintained branch on September 17, 2026: version 7.1.1 for the current release line, plus backported fixes at 7.0.5, 6.9.8, and 4.7.36 covering older branches still receiving security updates. Researcher Rafie Muhammad is credited with the discovery. As of publication there’s no evidence of active exploitation in the wild, and it isn’t on any government actively-exploited-vulnerabilities list, which is the good news. The less good news is that a CVSS 7.1 unauthenticated bug affecting core versions going back to 4.7 is now public knowledge, and every unpatched WordPress install on the internet is a matching target.
Our take
This is the third time in recent memory that a formatting or sanitization edge case in WordPress core, not a plugin, has turned into a real path to remote code execution, and it follows a pattern we keep seeing across the ecosystem: the actual danger in WordPress security rarely sits in the obvious places. Nobody audits the comment reformatting pipeline expecting to find an RCE chain there, because on paper it’s just text display logic. That’s exactly why it’s worth auditing. The plugins ecosystem gets the bulk of security attention because plugins get exploited constantly and at scale, and rightly so, but core itself is not immune, and a bug at this layer touches every single WordPress site regardless of which plugins it runs or which theme it uses.
The other thing worth sitting with is how little privilege the attack actually requires to start. No account, no login, just a comment field working exactly the way it’s supposed to. The distance between “anonymous visitor” and “administrator session” here is one page load by the wrong person, and that’s a distance most site owners assume doesn’t exist.
This isn’t the first core-adjacent shell we’ve covered
WordPress’s scale means a single core-level bug reaches an enormous number of sites at once, and we’ve tracked this pattern before. Earlier this year we broke down how a W3 Total Cache flaw exposed more than a million WordPress sites to unauthenticated remote code execution, and separately how a vulnerability in the Elementor plugin enabled complete site takeover. Different components, same underlying lesson: on WordPress, the path from a low-privilege input field to full server control is usually shorter than site owners assume.
What to do right now
- Update to WordPress 7.1.1, or the matching patched release for your branch (7.0.5, 6.9.8, 4.7.36), immediately. This is not a “schedule it for next maintenance window” patch given the CVSS score and the lack of authentication required.
- Don’t treat comment moderation as your security boundary here. It reduces exposure, it doesn’t close it, since the moderation screen itself is exactly where an administrator views pending, unpatched comments while logged in.
- If your site runs an older, unsupported WordPress branch that didn’t get a backported fix, that’s now a genuinely urgent upgrade, not a someday item.
- Get a real WordPress security review rather than relying on the plugin list alone, since this bug lived in core the whole time, untouched by any plugin decision you made.
- Pair patching with two-factor authentication on admin accounts, so that even if a session gets hijacked through a flaw like this one, a stolen cookie alone isn’t enough to act as that administrator going forward.
- A web application firewall in front of WordPress catches a meaningful share of exploitation attempts against bugs like this before they ever reach the comment-rendering code, which matters most in the window between disclosure and when every site actually gets patched.
- If you suspect a site was already hit before you patched, don’t just update and move on. Get a proper hacked website cleanup to confirm no plugin or shell was already dropped through an admin session.
- If you want to know what an attacker could actually reach on your specific WordPress setup, not just in theory, a scoped penetration test will tell you before someone less friendly does.