WordPress patches comment XSS flaw CVE-2026-93485 with fixes backported to 4.7

WordPress has shipped patches for a serious flaw in its comment system that allows a single anonymous comment to inject running JavaScript into a page, and from there potentially take over the server. Tracked as CVE-2026-93485 and nicknamed Comment2XSS (originally disclosed as Comment2Shell), the vulnerability affects WordPress core versions 4.7 through 7.1. According to a technical write-up on dev.to, the fix ships in 7.1.1 and has been backported to every supported branch — 7.0.5, 6.9.8, and older releases down to 4.7.36. The bug carries a CVSS 3.1 score of 7.1, rated High, and was reported by Rafie Muhammad of Awesome Motive through the WordPress HackerOne bug bounty program.

Two passes over the same HTML

When a comment is submitted, WordPress runs it through KSES, an allowlist-based sanitizer that strips tags and attributes it does not recognise. When that stored comment is later displayed, a chain of filters hooked to comment_text — wptexturize, convert_chars, make_clickable, force_balance_tags, convert_smilies and wpautop — rewrites the HTML a second time before output.

As the dev.to analysis explains, none of these filters misbehaves in isolation. The exploit is built on the mismatch between what the save-time sanitizer stored and how the display-time filters reinterpret that stored value.

How a newline becomes an event handler

The entry point is a newline character placed inside the cite attribute of a blockquote tag. cite is on the KSES allowlist, and the sanitizer's re-encoding table covers ampersands, angle brackets and quotes — but not newlines — so the attribute value is stored exactly as submitted.

At render time, wpautop, which wraps content in paragraph tags, has to distinguish newlines inside tags from newlines between paragraphs. It does this by swapping in-tag newlines for a placeholder HTML comment. That placeholder itself contains a greater-than sign, and this is where things break: a later wpautop regex, which locates the end of a blockquote's attribute list by matching any characters except a greater-than sign, stops at the placeholder's stray character instead of the real tag boundary. A cleanup step then writes a paragraph tag into the middle of the cite attribute value.

The injected paragraph tag is still inert text sitting inside an attribute — until wptexturize runs. That function converts straight quotes into typographic ones and, crucially, reads the injected tag as a genuine element boundary. The straight quote that followed it is rewritten as a curly-quote entity, destroying the original closing delimiter of cite. But wptexturize deliberately skips the contents of code, pre, kbd and similar tags, so a straight quote the attacker planted inside an allowed code element survives untouched and becomes the true closing delimiter.

The browser therefore ends the cite value early and parses the remainder of the attacker's text as real attributes on the blockquote — among them an onfocus handler paired with autofocus, which executes the moment the page renders, without any interaction from the reader.

The jump to remote code execution

The consequences go well beyond a scripted alert. The dev.to write-up notes that if a logged-in administrator views the poisoned page, the injected script inherits the administrator's own privilege to install plugins — which on WordPress amounts to the ability to run arbitrary code on the server. An anonymous comment can therefore chain stored XSS all the way to remote code execution.

Why it matters

Comment forms are open to strangers by design, and administrators routinely read their own comment sections while logged in, so the prerequisites for exploitation are ordinary site behaviour rather than exotic conditions. The affected version range stretches back to 4.7, which means a large share of installs that have not updated recently are exposed. The bug is also a textbook example of mutation-style XSS: no single function was broken, but the interaction of several HTML-rewriting filters allowed sanitized, saved content to become dangerous at output time. Sanitizing on input alone was not enough, and the same class of filter-interaction bug is worth auditing in any system that rewrites HTML multiple times before display.

What site owners should do

Update to the patched release for your branch: 7.1.1 for current installs, or the equivalent backport — 7.0.5, 6.9.8 and older releases down to 4.7.36 — for those on supported legacy versions. The write-up presents the update itself as the remedy and does not describe a configuration-level workaround, so sites that cannot patch immediately should treat unmoderated comments as a live risk.