WordPress shipped 7.0.4 on August 12, a security release the core team says to install at once. It closes a single flaw, tracked as CVE-2026-65640, that let a logged-in author turn an ordinary-looking image upload into code running on the server. The mechanism is an old one returning under a new name: a file called holiday.png that is not really a PNG at all. The catch that keeps it from being a five-alarm event is the account it needs, and the catch that keeps it dangerous is who tends to have that account.

Key facts

  • What it is. CVE-2026-65640 (GHSA-8vr3-7mxf-gx8w), an authenticated Author-and-above remote code execution through a malicious file upload, on any site whose server wires ImageMagick to Ghostscript. Reported by the team at pwn.ai and fixed before disclosure.
  • The trick. ImageMagick identifies a file by its contents, not its extension. WordPress trusted the extension. A file named .png that actually contains PostScript passed the upload check, reached ImageMagick, and was handed to Ghostscript, which ran it as a program.
  • How far back it goes. The flaw is present in WordPress core from version 4.7 through 7.0, almost 10 years of releases. Fixes are being backported to the 4.7 branch and to 7.1 RC3.
  • The gate, and why it is lower than it sounds. An attacker needs an Author account or higher. That is not an anonymous attack, but it is a realistic one on multi-author publications, membership sites, and client sites with contributors.
  • The bypass that matters. The normal upload screen would block the file. But XML-RPC’s upload method and the cover-art extractor for MP3s skip that check, so the payload still reaches the vulnerable code.
  • What to do. Update to 7.0.4. Sites on automatic background updates may already be covered. Prioritize any site that hands out accounts beyond a small, trusted team.

A PNG That Is Not a PNG

WordPress leans on ImageMagick, through the Imagick PHP extension, to resize and process everything in the Media Library. The trouble is that ImageMagick understands far more than JPEG and PNG. It also opens PostScript, EPS and PDF, and to render those it calls out to Ghostscript, a program with a long record of being talked into running commands it should not. This is the same family of problems as the “ImageTragick” bugs that rattled the web a decade ago, surfacing again because the underlying mismatch never fully went away.

The mismatch is this. ImageMagick decides what a file is by reading its contents, the first few “magic bytes,” and ignores the name. WordPress, meanwhile, was mostly trusting the name. So a file called holiday.png whose bytes actually begin with a PostScript signature cleared the upload checks, got handed to Imagick, which recognized the PostScript inside and fired up Ghostscript to execute it. The extension said image; the contents said program; ImageMagick believed the contents.

In code, the vulnerable method was WP_Image_Editor_Imagick::load(), which chose how to pass an uploaded file to ImageMagick based only on the extension and never looked inside. Content beginning with the right markers selected ImageMagick’s PostScript, EPS or WordPerfect-graphics decoder, and from there Ghostscript did the rest. One important condition rides along: the chain only fires where the server actually has Ghostscript wired to ImageMagick, which is not a given on every stack.

The Upload Screen Would Stop It. Two Other Doors Do Not.

WordPress does have a defense here. During a normal upload, the function wp_check_filetype_and_ext() inspects the file and catches this kind of mismatch. If every path into the Media Library went through it, the flaw would be far harder to reach.

Not every path does. Patchstack, whose security team documented the issue, points to two routes that skip the check: XML-RPC’s wp.uploadFile method and the cover-art extraction routine that runs on uploaded MP3s. Both write their bytes with a lower-level function that never inspects the content, so a booby-trapped file lands on disk and reaches the vulnerable decoder anyway. XML-RPC is enabled by default in WordPress and is reachable without touching the admin screens, which is what turns a theoretical mismatch into a usable path.

An Unauthenticated Path to Code Execution in WordPress Core, Already Being Exploited

Author Access Is the Only Thing Standing in the Way

The reason 7.0.4 is a serious fix rather than an emergency for every site is the account it demands. To reach the upload at all, an attacker needs to be able to add media, which means an Author-level role or higher. There is no anonymous, drive-by version of this.

The reason it is still worth prioritizing is who holds that role in practice. On a solo blog with a couple of trusted editors, exposure is small. On a multi-author publication, a membership site, or a client site full of contributors, the bar is far lower than it sounds. An Author uploading a poisoned image is then a genuine threat, not a hypothetical one. For a hosting company or an agency running such sites at scale, the honest reading is blunt: one compromised or malicious author account now converts into code execution on the server. That is a different blast radius from a defaced post.

What the Patch Changes, and What to Do

The fix, merged as commit 7daaa50, teaches load() to inspect a file’s real contents before it ever constructs the Imagick object, and to refuse anything bound for a dangerous handler. It now turns away:

  • PostScript and EPS, spotted by their signatures rather than their names
  • Fake PDFs that claim a .pdf extension without the real %PDF- marker
  • Compressed files that ImageMagick would quietly unpack to smuggle content past the checks
  • Format-specifier prefixes like EPS:innocent.png, while sparing Windows drive letters such as C:
  • The same tricks arriving through a remote URL or a stream, whose filenames it now parses before validating

The action is short. Update to 7.0.4; sites with automatic background updates enabled may already be patched, so it is worth confirming the running version. If updates are manual, move this one up the queue, above all on sites where accounts are handed out beyond a core team. Patchstack customers received a virtual-patch rule for the flaw ahead of updating. And there is a general lesson under the specific flaw, useful well past this release: the risky moment in media handling is the gap between what a file is named and what it actually contains.

About the Data

Details of the release, the CVE and GHSA identifiers, the reporter and the affected branches come from WordPress.org’s official 7.0.4 announcement of August 12, 2026. The technical analysis of the flaw, the vulnerable method, the XML-RPC and cover-art bypasses, and the contents of the patch come from Patchstack’s write-up by its security research lead, published the same day. The CVE record was not yet live at MITRE when this was written, so no third-party severity score is quoted; the release is described in WordPress’s own terms as an authenticated Author-and-above remote code execution.