WordPress 7.1.1 fixes unauthenticated XSS in wpautop()

WordPress 7.1.1, released on 17 September 2026, fixes 11 security flaws and 17 bugs in WordPress Core, and the most serious of them lets an anonymous visitor plant code on a site that accepts public comments. The flaw is an unauthenticated stored cross-site scripting (XSS) issue in wpautop(), the function that turns line breaks into paragraphs on nearly every piece of content WordPress renders. An XSS flaw is one in which an attacker gets their own code to run inside the browser of somebody visiting a site, as if the site itself had served it, and the word stored means the malicious content is saved on the site first and then handed to each visitor who loads the affected page. The vulnerability affects WordPress Core up to and including version 7.1 and carries the identifier CVE-2026-93485. It was reported by Rafie Muhammad and is set out in a Patchstack analysis, which states that the company's own customers are protected against it and which still recommends updating to the most recent version of WordPress available. The entry also has a CVSS 3.1 score of 7.1, under the vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L. CVSS is a widely used severity scale in which a higher number means a more serious flaw.

The entry point is what makes this one unusual. Patchstack's write-up notes that the attack needs no account at all. The payload is placed in an ordinary comment and submitted through the ordinary comment form by an anonymous visitor. It gets past wp_kses(), the WordPress component that cleans comments of dangerous markup, because nothing in the submitted text looks like the kind of markup that wp_kses() exists to strip. As stored, the comment appears harmless. It only turns dangerous later, when the site displays it and the display filters rearrange what is there.

The sink is wpautop() in wp-includes/formatting.php. Patchstack describes it as the one content filter in WordPress Core that does not parse HTML: it works on raw text using regular expressions, which are search and replace patterns, and one of those expressions was not aware of quoted attribute values. The pattern used in versions up to and including 7.1 captured everything between a paragraph tag and the first > character it met. That behaves correctly for a well formed tag, where the first > is the one that closes it. It breaks when a > shows up inside a quoted attribute value, because the expression then reads the middle of an attribute as the end of the tag and moves a paragraph element into it.

The attacker does not have to supply that > character. A few lines earlier in the same function, wpautop() protects line breaks that sit inside tags by swapping them for a placeholder, and that placeholder is an HTML comment. An HTML comment ends in -->, so a plain line break inside an attribute value becomes a > sitting inside an attribute value. WordPress's comment allowlist permits , and a line break inside that cite value is not something wp_kses() has any reason to remove. As Patchstack puts it, WordPress supplies the character the attack needs.

From there the tag is torn in half, the attribute's real closing quote is left stranded, and the remaining display filters finish the job. Attacker controlled text ends up in the part of the tag where attributes belong rather than safely inside an attribute value, so the result is script execution in the site's own origin for any visitor who loads the page, whether or not that visitor is logged in. Patchstack states that it is not publishing the breakout chain or a working payload. The fix in WordPress 7.1.1 makes the expression aware of quoting, so a > inside a quoted value no longer reads as the end of a tag.

One thing keeps the flaw from being a drive by attack. Patchstack notes that the comment has to be published. On a stock WordPress installation, a setting called comment_previously_approved holds a first time commenter's comment for moderation, so the payload sits in the queue until a moderator approves it. That slows an attacker down, but moderation is not a security control. Approving comments is routine work, the payload looks unremarkable in the moderation queue, and anyone whose comment has been approved before is auto approved from then on. Sites that accept public comments should treat this as the priority fix in the release, especially where moderation is delegated or where returning commenters are approved automatically.

The disclosure timeline, as Patchstack records it, starts on 15 September 2026, when Rafie Muhammad reported the issue to the Patchstack Vulnerability Disclosure Program, where it was validated and confirmed to have been communicated to the WordPress team. WordPress 7.1.1 was released with the fix on 17 September 2026, along with backports to older supported branches. The entry was published to the Patchstack vulnerability database on 18 September 2026.

The other ten fixes are mostly access control and disclosure problems, and most of them need an account with certain privileges on the site. Contributor level access was enough for an arbitrary post overwrite and for a path traversal in the REST API templates controller, both reported by Anthropic. A path traversal is a flaw that lets someone reach files outside the folder they are meant to be limited to, and the REST API is the standard interface WordPress exposes so that other software can read and change content. Contributor level access was also enough to disclose the slugs, the short identifying names, of draft and pending posts, reported by hermanhms. Any authenticated user could reparent comments, including notes, reported by viridis. Author level access was enough to publish changeset posts over XML-RPC, an older remote interface for outside software, in a way that skipped the custom CSS capability check, reported by Ben Bidner of the WordPress Security Team. The remainder are a stored XSS in custom header images on some themes and an HTML API issue that let modified text escape an HTML comment, both reported by Jeremy Felt of the WordPress Security Team; a crafted URL that could install and preview a theme from WordPress.org, reported by Paulos Yibelo and pwn.ai; a Multisite issue that let a site administrator network activate a plugin intended to be available only across a network, reported by Jesse McNeil; and an information disclosure exposing the title of a private parent post, reported by HDWSec. Multisite is a WordPress feature that runs several websites from one installation, and network activating a plugin means switching it on for every site in that network at once.

WordPress 7.1.1 is available from the Dashboard under Updates, or directly from WordPress.org, and sites with automatic background updates enabled will pick it up on their own. The WordPress team backported these fixes to older branches as far back as version 4.7; a backport is a fix written for the newest version that is then applied to an older version that is still supported. The release notes c