WordPress 7.0.4 Patches an Author+ Imagick RCE

Two Tuesdays ago the WordPress security team also shipped a release the same day 7.1 hit a milestone. That was 7.0.3, a twelve-fix roll-up on the day RC1 landed. This week they did it again — 7.0.4 on the same afternoon RC3 went out — and the pattern is starting to feel like the point rather than the coincidence. When a security queue and a release train run on top of each other for a fortnight without either wobbling, that is a project that has learned to keep the plates spinning in public.

The bug itself is a small classic. I first learned what PostScript was in 1993, feeding QuarkXPress output through an Aldus FreeHand round-trip so a print shop could impose signatures without redrawing the artwork. PostScript is a programming language; the fact Ghostscript will run it is not a bug, it is Ghostscript doing exactly what it was written for. WordPress trusting a file extension when ImageMagick does not is the seam. The team at pwn.ai found the seam, disclosed it responsibly through HackerOne, and the fix landed across every supported branch on the same day.

Two things to know before you read further. This is not the pre-authentication remote-code chain from July — that was 7.0.2. This one needs an authenticated Author. And it does not affect every server; you need a specific pair of ingredients on the box for the exploit path to open.

What is actually new

WordPress 7.0.4 shipped on August 12, 2026, authored by John Blackbourn. It patches CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w, rated 8.8 High. The advisory names it plainly: “remote code execution via malicious Postscript file upload by an Author level user or higher”, weakness class CWE-434 (Unrestricted Upload of File with Dangerous Type).

The exploit needs two conditions to line up on the same server. First, the site has to use Imagick as its image editor and the underlying ImageMagick install has to keep the Ghostscript delegate enabled. Second, the attacker needs an account with the upload_files capability, which by default means Author or above. On such a server, an uploaded file with a .png extension whose actual bytes are PostScript passes the WordPress mime check, gets handed to ImageMagick (which identifies by content, not extension), and reaches Ghostscript, which happily executes what it thinks is a program.

The technical fix is a single file. Per the 7.0.4 documentation page the only change is wp-includes/class-wp-image-editor-imagick.php. No package updates, no schema changes, no bundled-library bumps. This is a targeted patch on the image-editor class, not a maintenance release with security snuck in.

What is worth reading twice is the backport list. The same fix has been cut, tagged and released across every supported branch back to 4.7 — that is 4.7.35, 4.8.30, 4.9.31, and every 5.x and 6.x line through 7.0.4. Twenty-two point releases in one afternoon. WordPress 4.6 and earlier no longer receive security updates, and the notice on the release post is unusually blunt about the same message it has been repeating for years: “only the most recent version of WordPress is actively supported.” The courtesy backports exist so nobody trapped on an older major has an excuse to stall; they are not an invitation to stay there.

Why it matters for WordPress / WooCommerce people

The Author threshold sounds reassuring until you look at your actual role map. On a WooCommerce store, Shop Manager holds upload_files. On editorial estates, every contributor who was ever bumped to Author “temporarily” for a launch still has it. On membership sites and community platforms, a self-service registration form that grants Author on approval is the same threat model as a wide-open front door, only slower.

Server exposure is narrower than the vulnerability sounds. Most managed WordPress hosts either use GD instead of Imagick, or use Imagick with the Ghostscript delegate disabled in policy.xml — the same lesson the industry took from the ImageTragick era a decade ago. The stores worth checking twice are the older self-hosted VPS installs and any bespoke stack where someone once enabled Ghostscript to render PDF thumbnails and never revisited the decision.

The broader signal is the one I want on the record. In four weeks we have had 7.0.2 (a pre-auth RCE chain), 7.0.3 (a twelve-fix roll-up), and now 7.0.4 — each shipped with same-day parallel backports across every supported branch, each attributed to a specific researcher via HackerOne, each documented at file-and-line granularity. That is what a functioning security pipeline looks like from the outside. You do not get to see this on a hosted commerce platform where “we deployed a fix” is the entire forensic trail.

What I would do (or not do) about it

First, prove the fleet. On every site under management, either verify via the Dashboard, run wp core version over SSH, or grep $wp_version from /wp-includes/version.php. Auto-updates should already have carried you to 7.0.4 (or the matching backport for older majors). Sites that had auto-updates policy-disabled “for stability” are today’s patching queue — that is the exact policy this release argues against.

Second, check the delegate. On any self-hosted server where the image editor is Imagick, look at /etc/ImageMagick-7/policy.xml (or the 6.x equivalent) and confirm the ghostscript, PS, PS2, PS3, EPS, and PDF coders are set to rights="none". On a modern managed host this is almost certainly already done. On a legacy box it may not be. Either way you are patched by 7.0.4; policy hardening is defence in depth, not a substitute.

Third, spend fifteen minutes on the Author+ roster. Users → All Users, filter by Author, Editor and Shop Manager, deactivate anything dormant, rotate application passwords on anything active, and while you are there review any self-service registration flow that grants above-Subscriber on approval. This is the audit the vulnerability makes cheap to justify.

Two things I would not do this week. Do not install any third-party plugin whose pitch is “adds Imagick hardening” or “blocks malicious file uploads” — the fix is in Core, the delegate policy belongs on the server, and inserting a third-party layer between you and either is exactly the wrong direction of trust. And do not stack this audit on the same change window as the 7.1 GA upgrade on the 19th. 7.0.4 is a one-file patch that should have flowed through auto-updates already. Roll the Author-role review into a separate slot next week when 7.1 has settled.

A calm patch shipped on schedule, backported nine years, credited to the researcher who found it, documented at file-and-line granularity — that is the trust story you can put in front of an enterprise client without a slide deck. It is also why we still build the enterprise stack on this platform.