WordPress 7.1 Is Not a Security Release. One Part of It Still Matters for Security.

WordPress 7.1 shipped on 19 August. If you read the release post you saw responsive block styles, a Tabs block, a Playlist block, image processing moved into the browser, and Notes with mentions. If you read the security press you saw nothing, because there was nothing. 7.1 carries no CVE fixes. The security work happened in the month before it, in three point releases to 7.0, and if you are on 7.0.4 you already have all of it.

That makes 7.1 an easy release to file under "not my problem". Mostly that is right. This post is about the two places where it is not.

The point releases you should already have

The 7.0 line took four point releases between 9 July and 12 August, and three of them were security fixes.

7.0.2, 17 July. Two SQL injection issues, one of them reachable through the REST API's batch route without an account and leading to remote code execution. WordPress pushed it as a forced update and backported it to 6.9.5 and 6.8.6.
7.0.3, 6 August. Twelve fixes. The headline was a pre-authentication reflected cross-site scripting flaw on the login page, CVSS 8.9, present since 4.7. Also in the list: a multisite privilege escalation, a server-side request forgery, and an email confirmation bypass.
7.0.4, 12 August. One fix, CVE-2026-65640. An Author-level account could upload a PostScript file named as a PNG and, on a server with Imagick and Ghostscript installed, have Ghostscript run it. That path had been in core for almost ten years.

The check takes a few seconds: wp core version on the command line, or Dashboard, then Updates. If the answer is anything below 7.0.4, the finding is not "I need to update". The finding is that minor auto-updates, which are on by default, did not run on your site, and you need to know why before you do anything else. Next week's post is about that.

The change that matters: abilities can now be short-circuited

7.0 shipped the Abilities API, a registry where core and plugins declare machine-readable actions, and the MCP Adapter, which exposes those actions to AI agents over HTTP. I wrote about the surface that creates in August. The short version: every ability carries a permission callback, and that callback was the gate. An agent could only run what the callback allowed.

7.1 adds four lifecycle filters around every ability call. Two of them change the gate.

wp_pre_execute_ability runs at the very start of execution, before input validation and before the permission check. If any hooked code returns something other than the default, the ability's own pipeline never runs and that returned value goes straight back to the caller. wp_ability_permission_result runs after the permission callback and can overturn its answer in either direction.

Core added them for sensible reasons: caching an expensive result, rate limiting, putting a site into maintenance mode, adding an approval step. The core developer note is careful to say the pre-execute filter bypasses everything, permission checks included, and that is the point of it. But a filter is a filter. Any active plugin can hook either of them, and a plugin that does so sits between every agent and every permission check on the site.

On a site that runs the MCP Adapter, or any plugin that "adds AI abilities", this is now part of the audit:

grep -rlE "wp_pre_execute_ability|wp_ability_permission_result" \
  wp-content/plugins wp-content/mu-plugins

Every hit is code that can decide who runs what. Read it. Until you have, treat a plugin hooking wp_ability_permission_result the way you would treat one that registered an ability with a permission callback of __return_true, because that is what it can amount to.

One more consequence for logging. The wp_before_execute_ability and wp_after_execute_ability actions that 7.0 gave you do not fire when a call is short-circuited, so an audit log built on them misses exactly the calls a hostile plugin would want hidden. 7.1 adds wp_ability_invoked, which fires for every invocation, including the ones that fail validation, fail the permission check, or get short-circuited. Log on that.

If you do not run the adapter and nothing on the site calls abilities, none of this is work today. It is a reason to audit before you turn it on.

Image processing moved into the browser. The server rules stay.

The most interesting engineering in 7.1 is that uploads are now resized, converted and rotated in the browser before they leave the user's machine, using libvips compiled to WebAssembly. An iPhone HEIC becomes a JPEG on the way out. The server never sees the original and never runs Imagick on it.

For the class of bug 7.0.4 fixed, that is genuinely good. It is not a reason to relax any server-side rule, for three reasons. It only works in Chrome and Edge 137 and later; Safari and Firefox fall back to the server pipeline. Anything that posts to /wp-json/wp/v2/media directly, whether an agent, a script or an attacker holding an Author's Application Password, skips the browser entirely. And the file that reaches the server is still a file the server has to handle.

So the block on PHP execution in the uploads folder stays, the Imagick policy stays, and core stays patched. 7.1 narrows the path. It does not close it. Hosts that need to turn the browser-side processing off can do so with the wp_client_side_media_processing_enabled filter.

The WP Rocket morning

On launch day, every site running WP Rocket 3.23.2.1 or older went down with a fatal error on every request. 7.1 changed how WordPress builds the identifier for a hook callback, and WP Rocket's Cloudflare integration assumed that identifier was always a string. It was not any more. The fix, 3.23.2.2, shipped on 20 August.

Two details are the lesson. A site that is fatally erroring on every request cannot update anything from wp-admin, so the fix was to deactivate the plugin over SFTP by renaming its folder, update, and reactivate. And the rollback protection WordPress added in 6.3 did nothing here, because it watches for a plugin update that fails. No plugin update failed. A core update succeeded, and a plugin that was working stopped.

This is not a WP Rocket story. The handbook recommends WP Rocket and still does; the bug was a one-line assumption about a core internal. It is the reason major versions stay a manual, staged update while minor versions apply themselves. Majors break plugins far more often than they break core, and the plugin that breaks is rarely the one you would have guessed.

Everything else is not security

For completeness, because people keep asking: the admin bar is now visible in the editor; there is an Identity screen for title, tagline and icon; the Tabs and Playlist blocks are new; the Media Library's infinite scroll is back on by default with a per-user setting to turn it off; hosts can set WP_SPECULATIVE_LOADING_DEFAULT_MODE and WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS in a fleet's configuration, although the defaults did not move; and jQuery UI is now 1.14.2, which is a small, real improvement in a library that has had its share of advisories.

None of that changes your hardening. If someone tells you to upgrade to 7.1 for security, they have the wrong release. Upgrade to 7.0.4 for security, and move to 7.1 when your staging site has run it for a couple of days, because it is the branch new fixes will land on first.

Where this fits

Chapter 14 of the Protect My WP handbook covers the AI agent surface end to end, and was updated this week for the 7.1 filters: how to find the plugins that hook them, and which action to log on so a short-circuited call still shows up. Chapter 1 has the Imagick note and Chapter 8 the update policy the WP Rocket morning argues for.

Get the book for £19.