Comment2XSS: A Comment Becomes Stored XSS, Then an Admin-Session RCE Chain
WordPress fixed a second core remote-code path this month — and this one starts with something every site invites: a comment. CVE-2026-93485, researched by Awesome Motive's Rafie Muhammad and disclosed through the WordPress bug-bounty program under coordinated disclosure, is an unauthenticated stored XSS in WordPress core's comment-rendering chain, fixed in WordPress 7.1.1 on 17 September 2026 with the fix backported to every supported branch down to 4.7. Patchstack assigned the CVE on 18 September and rates it 7.1. There is a companion from the same week — the page-template LFI-to-RCE flaw now in CISA's KEV — but this is a different bug with a different lesson, and it lives in the gap between sanitizing input and formatting output.
The vulnerability is a cascading transformation across filters that were each “safe” in isolation. On save, the KSES sanitizer allows a blockquote cite attribute containing a newline. On display, the comment_text filter chain — wptexturize, convert_chars, make_clickable, force_balance_tags, convert_smilies, wpautop — rewrites the markup step by step. The newline survives into wpautop(), which replaces it with an HTML comment and injects an unexpected tag; wptexturize() then encodes a double quote, and the final render carries a live JavaScript event handler where the submitted comment held only benign text inside a code element. On a block theme — or certain classic-theme block-rendering paths — merely loading the page executes it. No click, no interaction: zero-click stored XSS from an anonymous comment, in configurations where comments post without approval.
XSS is the flaw; RCE is the chain — keep them distinct
Precision matters here because the naming invites overstatement (the research was even retitled from “Comment2Shell” at a maintainer's request to avoid implying direct shell access). The core flaw is stored XSS. Server-side code execution enters through the known WordPress escalation path: riding an authenticated administrator session to upload a plugin file. In other words, the comment plants script execution in the browsers of whoever views it — and if that includes an admin session, the attacker's JavaScript can drive privileged actions the server will honor as the administrator. That is a genuine path to site takeover, and the proof of concept demonstrates it, but it is a two-stage chain with a session requirement, not an unauthenticated RCE. Teams should triage it as critical stored XSS with a credible privilege-escalation endpoint, and not as a remotely exploitable shell in one request.
The architectural moral is one this site returns to often: sanitize-on-write plus transform-on-read is a composition bug waiting for alignment. KSES approved the stored form; the formatting pipeline produced a different, executable form. Any system that validates data at rest and then rewrites it at render — comment pipelines, agent tool-output formatters, LLM response post-processors — must validate the final rendered output, not just the stored input. The agent-security parallel is direct: it is the same shape as tool descriptions that are benign in a registry and malicious in a prompt.
What to do
- Update to 7.1.1 or the patched release in your branch. The fix is backported to every supported branch from 4.7 onward (down to 4.7.36) — but running an old branch below its own patched version leaves you exposed. Confirm your branch's fixed release, not just “7.1.1.”
- Require approval for comments if you do not already. The zero-click path needs the payload to reach rendering; holding comments for moderation breaks anonymous exploitation outright.
- Review recent comments for blockquote/cite payloads. Hunt stored comments containing
blockquotetags with newlines or encoded entities in attributes — the KSES-allowed shape this exploit wears. - Assume admin sessions are the target and scope their exposure. Limit who holds administrator roles, enforce phishing-resistant MFA, use separate browsers or profiles for admin work, and expire sessions aggressively — the RCE stage dies without a privileged session to ride.
- No observed exploitation yet — use the window. There is currently no sign of in-the-wild use and no KEV listing. Patch inside that window rather than after it closes.
Sources:
- IDNSEC — Rafie Muhammad (Awesome Motive), “Comment2XSS: Zero-Click Pre-Auth XSS to Potential RCE in WordPress Core” (21 September 2026; KSES/wpautop/wptexturize cascade, PoC, patch timeline, coordinated disclosure via HackerOne)
- The Hacker News — “WordPress Comment2Shell Flaw Can Turn Anonymous Comment XSS Into RCE via Admin Session” (fixed in WordPress 7.1.1 on 17 September; no observed exploitation; not in KEV)
- MagicWP — “Comment2Shell CVE-2026-93485” (unauthenticated stored XSS in wpautop(); Patchstack CVSS 7.1)