WordPress 7.1.1 Fixes a Comment-Form XSS. The Payload Passes the Sanitizer.

WordPress 7.1.1 was planned as a bug-fix release and shipped as a security one on September 17. The schedule the release leads published on September 2 says the version “is intended as a bugfix only maintenance release,” and the release candidate of September 10 said the same. The final build carries 11 security fixes, alongside 17 core fixes and the block editor fixes, counted as 19 in the release post and 21 in the version documentation, and asks site owners to “update your sites immediately.” The applicable fixes went out the same day to affected branches back to 4.7, as versions 7.0.5, 6.9.8, 6.8.9 and twenty-one more.

The fix that matters most for hosting providers is the one that needs no account. WordPress describes it as “an unauthenticated stored cross-site scripting (XSS) issue via paragraph formatting, subject to comment approval,” reported by Rafie Muhammad of Awesome Motive. Patchstack, which tracks it as CVE-2026-93485, with a CVSS 3.1 score of 7.1, is more direct about where the payload comes from: “an ordinary comment, through the ordinary comment form, submitted by an anonymous visitor.” It gets past wp_kses(), the sanitizer WordPress runs on comments, “because nothing in it looks like the markup wp_kses() exists to strip.” It turns dangerous only later, when the comment is displayed and the paragraph filter rearranges it. For a shared host, that is a flaw in every site that accepts anonymous comments, on a code path where a generic XSS signature has little to key on.

Key facts

• The flaw: CVE-2026-93485, a stored XSS in wpautop() scored 7.1. It arrives through the public comment form, needs no account, and runs when the approved comment is displayed.
• The gate: on sites that accept anonymous comments, the payload has to be published first. A first comment is held for moderation by default, but returning commenters can be auto-approved.
• The reach: all eleven fixes reached 7.0.5, 6.9.8, 6.8.9 and 6.7.8. Older branches received between ten and six of them, and nothing before 4.7.
• The blind spot: the comment POST carries none of the script markup a generic rule looks for. Patchstack and Pantheon both say they block it, and both still say to update.

A Paragraph Filter That Reads HTML Without Parsing It

wpautop() is documented as the function that “Replaces double line breaks with paragraph elements”, a filter on post content and excerpts. Patchstack’s analysis places it on the comment display path as well, which is why a flaw in it reaches the public comment form, and describes the fault as a regular expression that processes HTML without parsing it. The pattern that matched the opening of a blockquote inside a paragraph stopped at the first closing angle bracket it found, and that breaks when the same character appears inside a quoted attribute value.

Attackers do not have to supply that character themselves. Patchstack explains that WordPress protects newlines inside tags by replacing them with an HTML comment placeholder, and an HTML comment ends with a closing angle bracket. A newline inside an attribute value therefore becomes a bracket inside that value, and the regular expression misreads the attribute’s closing quote as the end of the tag. What follows, in Patchstack’s words, is “attacker controlled text” landing in attribute positions where it executes as script. The fixed pattern in 7.1.1 handles quoted attributes properly. The changed file list in the release documentation confirms the location. wp-includes/formatting.php, one of the thirteen files revised, is where the pattern lives.

A blockquote with a newline inside a quoted attribute does not look dangerous, so the comment sits in the database as harmless text until the display filters run. The submitted comment carries none of the obvious script markup a generic rule would look for, because the dangerous structure is assembled later, on output. That defeats a signature written against the comment POST. It did not defeat the vendors who wrote for this specific flaw: Patchstack states that its customers “are protected for the stored XSS” and still recommends updating, and Pantheon’s note says it “has pre-deployed platform-wide mitigations (virtual patching via our routing network) against external abuse of some of these vulnerabilities,” names CVE-2026-93485 among those covered, and still tells customers to update.

The Exploit Needs an Approved Comment. That Is a Weak Gate.

WordPress’s own description qualifies the flaw with three words: “subject to comment approval.” The comment has to be published before its script runs. On WordPress’s Discussion settings screen, the two controls that decide when that happens are “An administrator must always approve the comment” and “Comment author must have a previously approved comment.” Neither is a security control in the sense that matters here. The first one forwards the comment to a person who sees a plausible comment and approves it. The second one holds a first comment for moderation and waves through every comment after it from the same email address, and the email address is not verified.

On a stock install, first-time commenters are held for moderation, which slows an attacker down. The assessment from Patchstack is nonetheless that “moderation isn’t a security control,” with the advice to “treat this as the priority fix in the release, especially where moderation is delegated or returning commenters are auto-approved.” That describes a large share of the sites on any shared platform: blogs with a comment form left on, moderated by whoever has time, with returning commenters approved automatically. The people most likely to render an approved comment are the ones with the most valuable sessions, the administrators and editors who review the moderation queue and the pages the comment appears on. A stored XSS that executes in an administrator’s browser runs in the site’s own origin and can act with that session’s privileges.

Two Fixes From Anthropic, One From pwn.ai

Of the other ten fixes, two carry the same reporter. Anthropic, the AI lab, is credited with “a Contributor+ arbitrary post overwrite issue” and “an authenticated path traversal issue in the REST API templates controller.” The first needs a Contributor account, the lowest role that can write on a WordPress site, and the role hosts and agencies hand to guest authors and clients. WordPress does not state the role required for the second beyond “authenticated.” Paulos Yibelo and pwn.ai are credited with “an issue allowing a crafted URL to install and preview a theme from WordPress.org.” The August 6 release, 7.0.3, carried an Author-level CSS injection from Anthropic and a pre-auth reflected XSS on the login screen from pwn.ai. Six days later, 7.0.4 shipped to fix a single flaw, an Author-level remote code execution through file upload on sites using Imagick and Ghostscript, also reported by pwn.ai. An AI lab and an AI-driven security company are becoming a recurring presence in WordPress security credits.

The remaining seven span authorization, disclosure and XSS, all behind an authenticated account:

• Any authenticated user could reparent comments, including notes, reported by viridis.
• An XML-RPC issue let changeset posts bypass the custom CSS capability check, reported by Ben Bidner of the WordPress Security Team.
• Contributors could read the slugs of draft and pending posts, reported by hermanhms.
• An information disclosure exposed the title of a private parent post, reported by HDWSec.
• A stored XSS in custom header images on some themes, reported by Jeremy Felt of the security team.
• An HTML API issue “allowing modified text to break out of an HTML comment”, also from Jeremy Felt.
• A site administrator on multisite could network-activate a network-only plugin, reported by Jesse McNeil. On a platform run by a host, that is a tenant reaching a control that belongs to the network operator.

Twenty-Four Branches Patched, and the Share Still on Version 6

WordPress backported the fixes to affected branches as far back as 4.7. Older branches were affected by fewer of the eleven and received a fix for each one that applied to them:

• 7.0, 6.9, 6.8 and 6.7: all eleven fixed, as 7.0.5, 6.9.8, 6.8.9 and 6.7.8
• 6.6 down to 5.9: ten of the eleven apply, all ten fixed
• 5.8 through 5.6: nine
• 5.5 through 5.3: eight
• 5.2 through 4.8: seven
• 4.7.36, the oldest patched branch: six
• 4.6 and earlier: nothing, the branch no longer receives security updates

The release documentation repeats the line WordPress attaches to every backport: “only the most recent version of WordPress is actively supported.” That ladder is not academic on a hosting fleet. W3Techs’ version tracking for September 21 splits the installed base as follows. Version 7 holds 62.3 percent, version 6 holds 30.6 percent, version 5 holds 4.9 percent and version 4 holds 2.0 percent. The grouping is by major version, so 7.1 and 7.0 are counted together and the table cannot say how many sites run 7.1.1 itself. What it does show is that more than a third of WordPress sites sit on a major version older than 7, on a branch reached only by a backport. A site on 6.8 that took its automatic security update on September 17 is on 6.8.9 and is fixed. A site on a branch older than 4.7, or on any branch with automatic updates switched off, is not.

Two Hosts, Two Ways of Closing It

The mechanism WordPress leans on is stated in its release post: “If you have sites that support automatic background updates, the update process will begin automatically.” Some hosts do not wait for that. Reclaim Hosting told its customers on September 17 that patches “are being rolled out across all cPanel accounts on Shared Hosting, DoOO, and Managed Hosting”, along with standalone and multisite installations on its managed product, and told owners of self-managed installations on its cloud product to update themselves. Pantheon asked its customers on September 18 to “upgrade to WordPress 7.1.1 as soon as possible from your Pantheon dashboard or Terminus.” The difference is operational. Reclaim pushed core patches across its managed environments, while Pantheon put mitigation in its routing layer and asked customers to apply the WordPress update themselves.

For a provider that runs a fleet, the check is the version on each site, not the fact that a release exists. The branches to look for are 7.1.1, 7.0.5, 6.9.8, 6.8.9 and 6.7.8 for a complete fix, and the matching point release of any older affected branch, which carries every fix that applies to it. The site to worry about is the one whose owner disabled automatic updates because a plugin broke once and never turned them back on, with the comment form still open.

About the Data

The release date, the fix counts, the security issues with their reporters and the backport ladder come from the WordPress 7.1.1 release post and the version documentation pages, which also cover 7.0.3 and 7.0.4. The plan for a bug-fix only release comes from the release schedule and release candidate posts on Make WordPress Core. The CVE number, the CVSS score, the mechanism of the flaw, the reading of comment moderation and the protection claim come from Patchstack. Version shares are W3Techs’ figures for September 21, grouped by major version. Host responses are quoted from Reclaim Hosting’s and Pantheon’s own notices. Neither disclosure cited here reports exploitation of CVE-2026-93485 in the wild.