The bar across the top of your dashboard has probably been sitting there since Tuesday. It is a slightly alarming colour, it says a new version of WordPress is available, and nothing on the site appears to be broken. So it waits for a quieter week.
This month that bar is pointing at WordPress 7.1.3, and the quieter week is the thing to skip.
What actually shipped on 6 October
WordPress 7.1.3 was released on 6 October 2026. The official announcement calls it a maintenance and security release carrying seven security fixes and four bug fixes, and WordPress does not hedge: “Because this is a security release, it is recommended that you update your sites immediately.”
Those two halves, security and maintenance, are worth pulling apart, because owners usually only hear one of them.
The security half
Seven flaws in WordPress itself. Not a plugin, not your theme: the core software every page of your site runs on. In short, they are two cross site scripting issues (one that arrives as a pending comment and fires when a moderator opens the Comments screen, one in Imgur embeds), a second order SQL injection in the WXR export tool, a denial of service in an internal URL helper, an unauthenticated leak of comments left on private and unpublished posts, a logic error that let Author accounts pin posts to the top of the blog, and a hook naming collision that only bites with certain plugins installed.
Two terms, because they come up every time. Cross site scripting, usually shortened to XSS, means an attacker gets their own code to run inside someone else's browser, typically while that person is logged in as an administrator. SQL injection means feeding your database instructions it was never meant to run.
The seven were reported by Thomas Chauchefoin at Trail of Bits, Ananda Dhakal at Patchstack, Anthropic (three of them), the researchers Zhengyu Liu, Jingcheng Yang and Gavin Zhong, and Alex Concha of the WordPress security team.
The maintenance half
Four bug fixes. The announcement does not describe them one by one: it links to the ticket list instead. We could not find a plain English write up of the four, so we are not going to invent one. What the changelog does publish is the list of files revised across the whole release, and they are core plumbing rather than edge cases: the main query class, the customizer, the REST endpoint for posts, the HTTP class.
That half gets underrated. The security fixes stop somebody doing something to your site. The bug fixes stop your site quietly doing something odd on its own, which is the fault nobody can ever reproduce on the Friday it finally matters.
Security and stability are the same habit
An out of date site is not only a security story. It is also the site where a plugin update eventually fails because core is three versions behind, where the host moves to a newer PHP and something snaps, where nobody can say whether this week's strange behaviour is a bug or a break in. Falling behind compounds: the longer the gap, the bigger and riskier the eventual catch up.
Keeping core current is the cheapest single thing you can do for both sides of that.
How urgent is 7.1.3, honestly
Urgent enough to do this week. Not urgent enough to cancel anything.
WordPress published no CVE identifiers and no severity scores for these seven. A CVE is the public catalogue number a vulnerability is given so that everyone can refer to the same issue in the same way. Without one, there is no official ranking to point at.
Patchstack, whose own researcher reported one of the seven, sorted them by who can actually reach each flaw. Two can be started by an unauthenticated visitor, and one of those also needs a moderator to click. Three need a Contributor or Author account on your site. One needs an administrator to run an export. The last only matters if a plugin hands raw data to core. Their read was to update as soon as you can, but that this is not a drop everything emergency.
One thing we could not confirm, and we would rather say so than pad the piece. As of 8 October 2026, we found no report of any of these seven being exploited in the wild, and no public proof of concept code. That is unconfirmed, not disproved. Nobody reporting an attack is not the same as nobody running one.
Why “not an emergency” still means this week
The previous release is the argument, and it is a strong one.
WordPress 7.1.2 shipped on 22 September 2026 with a single fix: CVE-2026-87902, an unauthenticated path traversal in page template resolution that could load a PHP file from outside the theme and, under the right server conditions, turn that into remote code execution. Patchstack rates it 9.2 out of 10, critical, affecting WordPress 4.7.0 through 7.1.1. That range goes back to 2016.
Patchstack recorded probes for it on 22 September, the same day the patch went public, within hours of release. By the next day the traffic had moved past reconnaissance: attackers were using the flaw to write their own PHP onto servers, and public scanning tools for it were already circulating.
That is the mechanism worth understanding. Publishing a patch also publishes the bug. Anyone can read the change and work backwards to the attack, and the gap between a release and the first scans is now measured in hours rather than weeks. Right now 7.1.3 is sitting inside that gap with nothing confirmed against it. The window is the whole reason to update before you know you need to.
Old branches got the fix, which is not the same as being safe
WordPress says the fixes are being backported, where necessary, to every branch still eligible for security fixes, currently as far back as 4.7. WordPress 7.0.7 went out on 6 October alongside 7.1.3.
Read the line WordPress puts next to that, though: “only the most recent version of WordPress is actively supported.” A backport is a courtesy, not a support contract. If you are sitting on a 5.x or 6.x branch, installing the patch is the easy half of the job and planning the move to a current version is the real one.
Where updating sits in site health
Updating core is one habit out of about five, and the other four are what turn an update from a risk into a routine.
- Know whether automatic updates are on. Minor releases like 7.1.3 install themselves by default, and have since WordPress 3.7, but hosts, plugins and old
wp-config.phpedits all switch that off and nobody remembers doing it. Tools, then Site Health, then Status will tell you whether background updates are working on your install. - Back up before, not after. An update that goes wrong is a ten minute problem with a backup and a very long day without one.
- Look at the site afterwards. Load it as a visitor, click through a few pages, send yourself a message through the contact form. Updates rarely break anything. Rarely is not never.
- Clear your caches, including the CDN. A patched site can still serve a page that was cached before the patch.
- Prune the user list. Several of the seven need a Contributor or Author account to get going, so the practical question is who holds one. Users, then All Users: the old freelancer, the ex employee, the account nobody remembers creating.
What to do this week
- Take a backup.
- Go to Dashboard, then Updates, and install the latest version offered for your branch. On a current site that is 7.1.3.
- Check the front of the site and one form.
- Clear the caching plugin and the CDN.
- Open Tools, then Site Health, and turn automatic background updates back on unless there is still a live reason they are off.
- Delete the user accounts nobody needs.
That is twenty minutes on one site. It is an afternoon across a dozen, every time core ships, and core has shipped three times on this branch since mid September. If you would rather that afternoon was someone else's, that is the job Wurdey does: we watch the advisories, apply the updates, check the sites afterwards, and tell you what changed.
Sources
Next step
Rather not do all this yourself?
Wurdey care plans handle updates, backups, security and monitoring for one monthly price, hosting included, from $49 a month. Free migration, and a real team on the other end.