WordPress 7.1.1 Patches 11 Security Flaws

WordPress 7.1.1 lands four weeks after WordPress 7.1 "Mary Lou" and is what the release team calls a short-cycle release, with the next major version, 7.2, currently planned for December. The maintenance fixes are routine stabilisation work on a month-old major. The security load is not routine: eleven separate vulnerabilities, credited to nine separate reporters, closed in a single release.

The detail that matters more than the version number is how far back the patches go. Every WordPress branch from 4.7 upwards received a backport, which is the security team's way of saying these issues were judged serious enough to be worth reaching installs that are more than eight years old. If you manage a portfolio of sites, that is the line to act on.

How the release reaches your site

WordPress has shipped minor releases through automatic background updates by default since version 3.7, and 7.1.1 is a minor release. On a standard install with nothing overridden, the update applies itself without anyone logging in. For most sites the practical question is therefore not whether to update but whether the update actually happened, and when.

That default gets switched off more often than people expect. Managed hosts sometimes stage core updates on their own schedule, Composer-managed installs pin the core version in a lockfile, and plenty of agencies have set WP_AUTO_UPDATE_CORE to false on a site where a fragile plugin once broke on a point release and nobody ever turned it back on. Those sites will sit on 7.1 until somebody presses the button.

The backport matrix is unusually long. WordPress 7.0, 6.9, 6.8 and 6.7 are affected by all eleven vulnerabilities and received 7.0.5, 6.9.8, 6.8.9 and 6.7.8 respectively. Branches from 6.6 down to 5.9 are affected by ten of the eleven, 5.8 through 5.6 by nine, 5.5 through 5.3 by eight, 5.2 through 4.8 by seven, and 4.7 by six, closing at version 4.7.36. WordPress 4.6 and earlier no longer receive security updates at all.

Worth being clear about what a backport is and is not. The version documentation describes these older-branch releases as a courtesy, and repeats that only the most recent version of WordPress is actively supported. A site running 5.8.16 has had these eleven issues closed. It has not become a supported install.

What the eleven vulnerabilities cover

Only one of the eleven is described as reachable without a login. That is a stored cross-site scripting issue in wpautop(), the function that turns line breaks into paragraph markup, which allows an unauthenticated visitor to inject script through paragraph formatting. It is gated on comment approval, so the payload has to be let through by a human or by an auto-approval rule before it fires. It was reported by Rafie Muhammad of Awesome Motive.

The largest group needs only a low-privilege account. A Contributor or above could overwrite arbitrary posts, and could disclose the slugs of draft and pending posts. Any authenticated user could reparent comments, including notes. A missing read_post check in attachment_submitbox_metadata() leaked the title of a private parent post. On a site where Contributor is handed out to guest authors, freelancers or a client's wider team, that is a realistic starting position rather than a theoretical one.

A second cluster sits around themes. There is a stored XSS issue in custom header images on some themes, and a separate issue where a specially crafted URL could automatically install and preview an inactive theme straight from the WordPress.org directory. The remaining fixes are more structural: an HTML API flaw where set_modifiable_text() allowed content to break out of an HTML comment using abrupt-closing sequences, an authenticated path traversal in the REST API templates controller, a multisite issue letting a site administrator network-activate a network-only plugin, and an XML-RPC route that could publish customize_changeset posts while bypassing the edit_css capability check.

It is worth putting the Contributor-level issues into a concrete shape. Take a UK trade publisher that accepts guest articles and gives each contributor an admin account so they can draft in place rather than email documents back and forth. On unpatched code, one of those accounts could overwrite a post it does not own, which on a commercial site means a live published article could be replaced with copy the editorial team never approved. The same account could read the slugs of unpublished drafts, which on an embargoed story is the leak in itself. Neither step involves escalating to Administrator. Both only require an account the site issued deliberately, to somebody it has no particular reason to trust with everything.

One credit in the list is worth noting on its own. Two of the eleven, the Contributor-level arbitrary post overwrite and the REST templates path traversal, are credited to Anthropic. AI-assisted review turning up genuine authorisation bugs in a codebase as heavily audited as WordPress core is a reasonable signal that the volume of disclosed core issues goes up rather than down from here.

What this means for UK site owners and agencies

For the majority of UK sites the honest answer is that the work is verification, not firefighting. Background updates will have moved most installs to 7.1.1 within hours of the 17 September release. The job is to confirm it across every site you are responsible for rather than assume it, and to have a list of the ones where the automatic path is switched off.

Verifying at portfolio scale is quicker than it sounds. WP-CLI reports the installed version with wp core version, and wp core check-update will say whether the site believes an update is still pending, which is the more useful of the two when you are hunting for installs where the automatic path has been switched off. Without shell access, the Updates screen in wp-admin answers the same question, and the site's generator meta tag will often confirm the version from outside, although plenty of security plugins strip that tag on purpose. Whichever route you take, record the result per site rather than spot-checking the ones you happen to remember.

The exposure is concentrated, and it is concentrated on multi-author sites. Publishers, membership sites, charities with volunteer editors, WooCommerce stores with warehouse and support staff accounts, and any client site that has accumulated old Contributor logins from a previous agency or a departed freelancer. Ten of the eleven are framed around an account or a capability rather than an anonymous visitor, so the population at real risk is the population that hands out logins. If you run WordPress maintenance for clients, the role audit is the part of this release with lasting value, because dormant low-privilege accounts outlive any single CVE.

Comment handling is the other control worth checking this week. The one unauthenticated vector depends on a comment being approved. Sites that hold every comment for moderation have a human in the path. Sites that auto-approve comments from previously approved authors, which is a default many UK small-business sites have never touched, do not. That setting sits in Settings, then Discussion, and takes seconds to review. The NCSC's guidance on keeping software up to date makes the same general point that patch latency, not patch availability, is where most organisations actually lose ground.

Practical considerations

The revised file list is short enough to be useful. It includes wp-includes/formatting.php and wp-includes/html-api/class-wp-html-tag-processor.php, both of which sit underneath almost everything that renders content. If a regression appears on your site after this update, a plugin doing something unusual with wpautop() or with the HTML API tag processor is the first place to look, not the block editor. The rest of the list is confined to theme, customiser, XML-RPC, template and comment endpoints.

The 19 block editor fixes also mean editing behaviour can shift slightly. That is normally invisible, but on sites with custom blocks or heavily filtered editor configuration it is worth a pass on a staging copy before the change reaches a client's editorial team. This is the same caution that applied to the 7.0.4 security release in August, and the same answer holds: a staging environment is what turns a security update from a decision into a routine.

Finally, keep the scope straight. This release patches WordPress core. It does nothing for the plugins and themes sitting on top of it, which is where the large majority of real-world WordPress compromises still start. With 7.2 not due until December, 7.1 is now in its stabilisation window, and the sensible use of the next three months is bringing the rest of the stack up to the same standard rather than waiting for the next core release to prompt it.

FAQ