WordPress 7.0.4: The Bug Is Not in WordPress, It Is in the Handoff

WordPress shipped 7.0.4 on Wednesday to fix a high-severity flaw, CVE-2026-65640, that lets an authenticated attacker execute arbitrary code on the server ^[1][2]. The bug matters less for its CVSS 8.8 rating than for the shape of it: this is a disagreement between two pieces of software about what a file is, and that class of defect tends to recur ^[2][7].

The mechanics are simple enough to explain in one breath. WordPress decides what an uploaded file is by looking at its extension, and hands it to ImageMagick through the Imagick extension on that basis ^[7][8]. ImageMagick does not care about the extension; it reads the contents, and if it finds PostScript inside, it calls Ghostscript to render it ^[8]. So a PNG with PostScript in the body arrives as an image and leaves as a program ^[9]. According to Patchstack, the vulnerability management firm that documented the chain, WordPress does have a function that performs content checks, but some upload paths do not use it ^[10].

The preconditions are narrow and specific, which is the useful part for anyone doing triage. WordPress says the issue affects only installations that use Imagick and Ghostscript, and that exploitation requires file upload rights, with Author-level permissions or higher ^[4][5][3]. All three conditions have to hold at once, so removing any one of them - the Imagick extension, the Ghostscript delegate, or untrusted accounts with upload rights - closes the path on that host ^[11]. WordPress attributes the underlying problem to Ghostscript's handling of certain embedded files ^[4].

The fix is a content check placed where the trust boundary actually is. WordPress modified the load() function to inspect a file's contents before passing it to Imagick, and also blocked the use of filenames to steer Imagick into invoking Ghostscript ^[12]. That second half is the tell: the extension was not the only string an attacker could use to influence delegate selection ^[12].

Note the backport range. The fix went to 7.0.4 and, as a courtesy to older branches, back to 4.7 ^[6]. That is a long tail of releases sharing the same assumption about extensions, and it is a reasonable proxy for how long the mismatch has been sitting in production ^[6].

Patchstack's framing of the risk is the right one for operators: if you run a multi-author publication, a membership site, or a client site with contributors and loose registration, an Author uploading a booby-trapped image is a realistic threat rather than a theoretical one ^[13].

What to watch: whether other Imagick consumers with the same extension-first logic get their own CVEs, since the disagreement is not WordPress-specific ^[7][8]. Watch for exploitation attempts against sites still on backported 4.x and 5.x branches, where patch application is slowest ^[6]. And check your own hosts for the Ghostscript delegate rather than assuming it is absent, because the vulnerable configuration is a combination, not a single package ^[4][11].