WordPress 7.0.4: Author-level Postscript upload RCE (CVE-2026-65640)

What WordPress 7.0.4 fixes

WordPress published GHSA-8vr3-7mxf-gx8w on 12 August 2026. The CVE is CVE-2026-65640. CVSS 8.8 (High). CWE-434: unrestricted upload of a dangerous type.

In plain English: on some hosts, WordPress will process a Postscript file that an Author uploads through the Media Library. Imagick hands that file to Ghostscript. Ghostscript has a weakness in how it handles certain embedded files. That is where remote code execution comes from. WordPress is the front door. Ghostscript is the room the payload reaches.

The fix shipped in WordPress 7.0.4, and as usual the WordPress security team backported it all the way to the 4.7 branch. You do not need to jump to 7.x to be patched. You do need the matching security release for whatever major you are on.

Credit for the disclosure goes to the team at pwn.ai.

Who is at risk from this WordPress 7.0.4 CVE

Two conditions have to line up. Miss either one and this particular path does not fire. That is not a reason to skip the update.

1. Imagick and Ghostscript on the server. Plenty of managed WordPress hosts ship both so image and PDF handling “just works.” Shared hosts and VPS images do the same. If you are not sure, ask the host whether ImageMagick (Imagick PHP extension) and Ghostscript are installed.
2. A user with the upload_files capability. On a default WordPress role map, that means Author and above: Author, Editor, Administrator. Contributor does not get Media Library uploads by default. Custom roles and membership plugins often add upload_files to “trusted” customers. Treat those the same as Authors for this advisory.

This is not an unauthenticated drive-by. Someone needs a legitimate (or stolen) Author-level account, or any account that can upload media. That still leaves a large blast radius: guest writers, agencies with shared Author logins, old contractor accounts nobody revoked, and any plugin that quietly grants upload rights.

If that sounds adjacent to WordPress XSS2Shell, it is the same family of problem from a site-owner point of view: core bug, security release out, update now. The mechanics differ. XSS2Shell started on the login page. This one starts in the Media Library.

How the Postscript upload RCE fits together

You do not need an exploit walkthrough to defend the site. The shape is enough.

1. Upload. A user with upload_files adds a malicious Postscript file through the normal media flow WordPress already allows.
2. Server-side processing. With Imagick available, WordPress (or the image stack around it) asks Ghostscript to handle Postscript content.
3. Ghostscript weakness. Certain embedded files inside that Postscript are handled badly. That is the RCE step. It runs as the same system user PHP runs as, often www-data.
4. Aftermath. From there an attacker can plant PHP, read wp-config.php, create admin users, or drop must-use plugins. Same cleanup story as any other webshell.

WordPress called out “certain installations.” That is the Imagick + Ghostscript prerequisite, not a vague “maybe you are fine.” If both are present and you still have unpatched core, assume you are in scope.

Patched versions for WordPress 7.0.4 and the backports

Update to the latest security release on your branch. On the 7.0 line that means 7.0.4. Older majors got matching builds, for example:

• 7.0.x: 7.0.4
• 6.9.x: 6.9.7
• 6.8.x: 6.8.8
• 6.7.x: 6.7.7
• 6.6.x: 6.6.7
• …and the same pattern back through 4.7.35

Full affected and patched lists are in the GitHub advisory. If Dashboard > Updates offers a security release, take it. Do not wait for a “convenient” maintenance window if Authors can already upload.

What to do about WordPress 7.0.4 today

1. Update WordPress to 7.0.4 or the backport for your major. Confirm the version under Dashboard > Updates (or At a Glance).
2. Audit who can upload. Users > All Users. Look for Authors, Editors, and any custom role with Media Library access you forgot about. Remove accounts that no longer need a login.
3. Review recent media. Especially Postscript / EPS-style uploads from the last few weeks if you have Author accounts you do not fully trust. Delete anything you did not expect.
4. If you were late: review Administrator users, unexpected plugins (including mu-plugins), and Application Passwords. Change passwords for remaining admins. For a proper pass, see WordPress malware removal and Fixing a Hacked Site.
5. Take a clean backup after you patch, so you are not rolling back onto a known-bad core build.

Hosting notes: Imagick, Ghostscript, and hard choices

Some teams will ask whether they should remove Ghostscript or disable Imagick. That can reduce exposure to this class of bug, and it can also break PDF thumbnails, EPS handling, and other media features your editors rely on. Patching WordPress is the first move. Server-side surgery is a second conversation with whoever runs the stack.

If you manage your own VPS, our WordPress server setup checklist is the place to keep “what image tools are installed” written down, not guessed under pressure.

WordPress 7.0.4 and BugShield

Core security releases are the boring kind of urgent. On Shield plans we apply WordPress updates as part of managed updates, next to monitoring and backups. Shield Pro adds malware scanning when you need a second pair of eyes on files after a scare.

If you only need this one patch handled, or the site already looks compromised, request a one-off fix or go straight to malware removal. And if you are still catching up on last week’s core issue, the XSS2Shell post and free XSS2Shell checker are still worth a pass. August has been busy.

Update to WordPress 7.0.4 (or your branch’s backport). Then look at who can still upload files. That is the whole job for most sites today.