A WordPress account with permission to upload files can turn a disguised image into server-side code execution on sites that process media with both Imagick and Ghostscript. WordPress fixed the path in 7.0.4 on August 12 and backported the change through branch 4.7.
The flaw, CVE-2026-65640, is rated 8.8 High. It is separate from the XSS2Shell login chain fixed in WordPress 7.0.3: this attack begins with an authenticated Author-level upload and reaches the server’s image-processing stack without administrator interaction. WordPress and its advisory do not report active exploitation, identify victims, or quantify how many installations use the vulnerable component combination.
An image crosses the boundary
WordPress accepts media from more than one route. Standard browser uploads normally receive file-type checks, but other paths can write bytes before the image editor loads them. The security boundary therefore cannot depend on the name supplied by the uploader.
On an affected installation, a malicious user needs the upload_files capability. WordPress grants that capability to the Author role by default, although site owners and plugins can change role permissions. The server must also use the PHP Imagick extension and Ghostscript.
The attacker presents content as an ordinary image. Imagick examines the bytes, recognizes PostScript or a related format, and invokes Ghostscript to process it. The WordPress advisory says the weakness is in Ghostscript’s handling of certain embedded files. Successful processing runs attacker-controlled code with the privileges of the web or PHP worker.
That prerequisite narrows the exposed population. A site using GD instead of Imagick, a server without Ghostscript, or an account without upload permission does not satisfy the published chain. Those facts do not make an affected site safe to leave unpatched.
Filename and content disagreed
Before the fix, WP_Image_Editor_Imagick::load() could treat the filename as the safe identity while Imagick selected a decoder from the content. Format prefixes created another identity signal: a name beginning with a value such as EPS: could steer Imagick toward a PostScript parser even when the remaining name looked benign.
The dangerous recognition values are useful for retrospective review. The patch identifies PostScript-family prefixes DPS, EPI, EPS, EPSF, EPSI, PS, and WPG; extensions including dps, epi, eps, eps2, eps3, epsf, epsi, ept, ept2, ept3, ps, ps2, ps3, and wpg; and byte signatures beginning %!, 04 25 21, C5 D0 D3 C6, or FF 57 50 43. It also rejects false PDF claims and compressed inputs identified as gzip, bzip2, or Unix compress.
Search web-server, reverse-proxy, WordPress audit, and file-integrity records for uploads with those content markers or misleading image extensions. Preserve the uploaded object, its hash, request metadata, actor, and the PHP or web-worker process tree. An uploaded file establishes staging. It does not establish that Imagick opened it, Ghostscript ran, or attacker code executed; process, child-process, file-write, response, or outbound-network evidence is needed for that conclusion.
Figure details
An authenticated WordPress user with upload_files submits a resource whose filename suggests an image while its bytes or format prefix identify PostScript. Vulnerable WordPress passes the resource to Imagick, which selects the PostScript path and invokes Ghostscript. Fixed WordPress reads the resource header, normalizes the provided name, and rejects PostScript formats, false PDFs, and compressed content before constructing Imagick.
Validation moves before Imagick
The WordPress fix commit reads the resource header before constructing an Imagick object. It derives a provided filename from local paths, URLs, or streams, strips and checks repeated Imagick format prefixes, and excludes Windows drive letters from that prefix logic.
The new loader rejects a file that claims a PDF extension without a %PDF- signature. It rejects PostScript by prefix, extension, or header, and blocks compressed content that Imagick would otherwise unpack before choosing a decoder. For a stream, WordPress validates the fetched bytes and passes the same bytes to readImageBlob(), avoiding a second fetch between inspection and use.
This is the important change: content validation now precedes the image-processing delegate. WordPress describes its release guidance directly: “Because this is a security release, it is recommended that you update your sites immediately.” The project credits the pwn.ai team with responsible disclosure.
Update every affected branch
WordPress 7.0.0 through 7.0.3 are fixed in 7.0.4. Older branches have distinct fixed backports:
| Affected branch | First fixed release |
|---|---|
| 6.9 | 6.9.7 |
| 6.8 | 6.8.8 |
| 6.7 | 6.7.7 |
| 6.6 | 6.6.7 |
| 6.5 | 6.5.10 |
| 6.4 | 6.4.10 |
| 6.3 | 6.3.10 |
| 6.2 | 6.2.11 |
| 6.1 | 6.1.12 |
| 6.0 | 6.0.14 |
| 5.9 | 5.9.16 |
| 5.8 | 5.8.15 |
| 5.7 | 5.7.17 |
| 5.6 | 5.6.19 |
| 5.5 | 5.5.20 |
| 5.4 | 5.4.21 |
| 5.3 | 5.3.23 |
| 5.2 | 5.2.26 |
| 5.1 | 5.1.24 |
| 5.0 | 5.0.27 |
| 4.9 | 4.9.31 |
| 4.8 | 4.8.30 |
| 4.7 | 4.7.35 |
Each fixed release supersedes the vulnerable build for CVE-2026-65640. WordPress says only its newest version is actively supported, so an old-branch security backport does not extend general support for that branch.
Verify the deployed boundary
Inventory production, staging, recovery, and forgotten campaign sites. Record the running core version, whether PHP loads Imagick, whether the host exposes Ghostscript, and which roles or custom accounts hold upload_files.
Run these checks from the deployed site and its application host:
wp core version --extra
wp eval 'echo extension_loaded("imagick") ? "imagick=yes\n" : "imagick=no\n";'
command -v gs && gs --versionThe expected result is WordPress 7.0.4 or later, or the exact fixed backport for the installed branch. Treat imagick=yes together with an available gs binary as confirmation that the published component prerequisite exists, then verify upload permission from the site’s actual role configuration.
After deployment, upload a known-good JPEG through every supported media path and confirm thumbnail generation succeeds. Submit a harmless test file whose .png name contains a PostScript %! header in a controlled non-production check; the expected result is a WordPress “File is not an image” error, with no Ghostscript child process. That runtime observation proves the validation boundary at its point of use. Version output alone proves only the declared build.