WordPress 7.1 – 19 Vulnerabilities in Three Releases, Including a Critical RCE (CVE-2026-87902)

The WordPress 7.1 branch is only a few weeks old, and it has already received three security releases in a row: 7.1.1 (September 17), 7.1.2 (September 22) and 7.1.3 (October 6, 2026). Together they patch 19 vulnerabilities — including one the WordPress team rated critical and that can be exploited without logging in. If your site is still on 7.1, 7.1.1 or 7.1.2, this post is for you.

WordPress 7.1.2 — a critical unauthenticated flaw (CVE-2026-87902)

We're starting with the middle release because it's the most urgent one. WordPress 7.1.2 shipped just five days after 7.1.1 and patches exactly one vulnerability (CVE-2026-87902, GHSA-7hp8-65ch-5whp):

• Local PHP file inclusion during page template resolution — under certain conditions, an unauthenticated attacker can make template resolution load a chosen, readable local PHP file located outside the active theme directories. If the server environment and the active theme meet additional preconditions, this leads to remote code execution (RCE).

The flaw was responsibly disclosed by Robert Ressl. In the official announcement the WordPress team tells users to update immediately, and the fix was backported to every branch eligible for security fixes — all the way back to 4.7. That's a meaningful difference from August's RCE in 7.0.3: that one required an Author account, this one requires no account at all. The preconditions limit how many sites are really exploitable, but you can't easily tell from the outside whether yours is one of them — it's safer to assume it is.

WordPress 7.1.1 — 11 security fixes

The first update to the 7.1 branch brought 36 bug fixes and eleven security patches. The WordPress.org announcement lists:

• Stored XSS in wpautop() — an unauthenticated visitor can inject script through a comment (subject to comment approval).
• HTML API, set_modifiable_text() — abrupt-closing sequences made it possible to break out of an HTML comment.
• Stored XSS in some themes that support custom headers.
• Installing and previewing an inactive WordPress.org theme via a crafted URL.
• Network-only plugin activation by a single-site Administrator on multisite installs.
• Path traversal in the REST API Templates Controller — for authenticated users.
• Publishing customize_changeset posts over XML-RPC, bypassing the edit_css capability check.
• Arbitrary post overwrite by a user with the Contributor role or higher.
• Private parent-post title leak — a missing read_post check in attachment metadata.
• Draft and pending post slug disclosure — reachable by Contributor or higher.
• Comment (and note) reparenting by any authenticated user.

Most of these need some kind of account — but look at how low the bar is. Contributor is the role guest authors and freelancers typically get, and "any authenticated user" on a WooCommerce store simply means every customer with an account.

WordPress 7.1.3 — 7 more fixes

The latest release (October 6) contains four bug fixes and seven security patches, described in the release announcement:

• Unauthenticated disclosure of comments on private and unpublished posts.
• Stored XSS on the Comments admin page, exploitable through a pending comment.
• Second-order SQL injection in the WXR export (Tools → Export).
• Denial of service in WP_Http::make_absolute_url().
• XSS in Imgur embeds.
• Author-role users being able to sticky posts.
• Action name collision in the {status}_{type} hook, caused by forgeable parameters.

The first two share a vector: comments. The attacker doesn't need an account — an open comment form is enough, and the malicious code runs in the browser of the administrator who opens the moderation queue. That's the classic path from "anonymous visitor" to a hijacked admin session.

What these three releases have in common

At the time of writing, the WordPress.org announcements for 7.1.1 and 7.1.3 don't list CVE numbers for the individual fixes — identifiers usually show up in vulnerability databases with a delay. That doesn't change the fact that each flaw's description and the patch itself are already public, so anyone can diff the versions and reconstruct the attack. The reporter credits are worth a look too: alongside independent researchers and the WordPress security team, they include teams using AI tooling for code analysis. The practical takeaway is simple — flaws are being found faster, so security releases ship more often, and the window between a patch and the first exploitation attempts keeps shrinking. Three releases in under three weeks looks more like the new normal than an exception.

How to check whether your site is affected

You'll find your WordPress version under Dashboard → Updates. Only 7.1.3 is safe — every earlier 7.1 release has at least seven known, publicly described flaws. If you're staying on an older branch, install its latest release (for 7.0 that's currently 7.0.7): fixes are backported to branches as far back as 4.7, although only the most recent version is officially supported and backports land there later. You can look up any core version in our public WordPress vulnerability (CVE) database, no account required.

If you monitor your site with MonitorWWW.com, the core version is checked against the vulnerability database automatically — you get an alert when the installed version has a known, unpatched flaw. More on how that works in Critical WordPress Vulnerabilities (CVE) — New in Monitoring.

How to update safely

• Take a full backup of files and the database before updating.
• If you have a staging environment, update there first and check your theme, page templates and the comment form.
• Update WordPress to 7.1.3 (Dashboard → Updates → Update Now). While you're there, make sure automatic minor-release updates aren't disabled — they're meant to deliver patches like these without you lifting a finger.
• If you can't update right away, temporarily switch to manual moderation for all comments (or turn comments off) and review your Contributor and Author accounts — remove the ones nobody uses anymore.
• After updating, test the key features: login, comments and, on stores, cart and checkout.

Summary

Nineteen vulnerabilities across three releases, one of them critical and unauthenticated, several more built on an ordinary comment form — WordPress 7.1 shows that "I updated a month ago" no longer means "I'm safe". At this pace, following release announcements by hand stops scaling, especially if you look after more than one site. Automatically comparing the installed version against a vulnerability database turns it into one concrete alert: this site, this version, this flaw — update.