It was called .png and inside it was PostScript: the WordPress 7.0.4 flaw

The file was called photo.png. It ended in .png, presented itself as an image, and ended up in the hands of the image processor without tripping anything. Nobody lied about the name. What was inside was something else: a program. That is what WordPress fixed on 12 August with release 7.0.4, and what makes the case interesting is the question it leaves open: who gets to decide what a file is.

We do not build WordPress sites and we do not make a living selling plugins. We do run the servers where client websites live, which is why this advisory interests us from a different angle than usual: not because of WordPress, but because of what it says about any application of yours that lets somebody upload a file.

What shipped, and when

WordPress 7.0.4 shipped on 12 August 2026 as a security-only release with a single fix. The advisory puts it plainly: "Authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript", and credits the responsible report to the team at pwn.ai. It is tracked as CVE-2026-65640 and as GHSA-8vr3-7mxf-gx8w.

The sentence that best measures the size of this is in the release note itself: the fix has been backported "through to the 4.7 branch", plus the 7.1 RC3 release. WordPress 4.7 shipped on 6 December 2016. The code being corrected today has been working exactly the same way for nearly ten years, across every branch in between, with nobody looking there.

That the backport stops exactly at 4.7 has an explanation no coverage has offered, and we give it as our reading rather than as a statement from the project: 4.7 is the release that introduced PDF thumbnail previews in the media library —it "now shows preview thumbnails instead of a generic icon for PDFs", says its documentation— and generating a PDF thumbnail is precisely what makes WordPress ask Imagick to call Ghostscript. The path being closed today opened the day that feature shipped.

A day later, on 13 August, Spain's INCIBE-CERT picked it up as INCIBE-2026-552 with a high severity rating and a description that points at the exact spot: Ghostscript does not safely handle certain embedded files, and an attacker with the upload_files capability could upload a malicious PostScript file, resulting in remote code execution. Keep that word, upload_files: it is the one that decides whether this concerns you, and we come back to it below.

Three programs, three opinions about the same file

A file uploaded to a website passes through several hands before it becomes the thumbnail a visitor sees, and each one looks at it differently:

None of the three is wrong on its own. The problem is that the opinion that counts is always the last one in the chain, and the first one is the doorman. Validating the extension is asking the file what its name is. It is the same pattern we wrote about with Tomcat a few days ago: a control that exists, that runs, and that still lets things through, because it checks something other than the thing that hurts.

There is a nuance most coverage skips, and it is worth saying even though it spoils the symmetry of the story: on a normal media library upload, WordPress does look inside. The wp_check_filetype_and_ext() function compares the real type against the extension and drops the file if they do not match. The catch is that not every upload path goes through it: according to the analysis by Cyber Security News, the XML-RPC wp.uploadFile method and the cover-art extraction routine for MP3s write bytes straight through wp_upload_bits(), which skips content inspection. One side door that does not ask is enough for the front doorman to stop counting.

The patch moves the check to the right place. The commit carries a title that sums up the whole fix —"Media: Prevent loading images into Imagick which might be PostScript"— and touches WP_Image_Editor_Imagick::load() so it inspects the content before building the Imagick object: it rejects PostScript extensions, rejects the binary signatures that identify an EPS or a PS, requires a PDF to genuinely start with %PDF-, and rejects compressed files that Imagick would unpack on its own. In other words: WordPress stops trusting the name on this path too and starts looking inside, which is what the program next door was doing all along.

Two conditions, and the first one is not yours to decide

For this to be exploitable on your site, both have to hold. The first is a server matter: image processing must use Imagick, and Ghostscript must also be installed. Plenty of installs use the GD library, where there is no delegation and therefore no such path. The awkward part is who makes that decision: not your theme, not your gallery plugin, not whoever writes the articles. It is made by whoever built the server or the container image, probably years ago, and they did not ask you.

The good news is you can check it without touching a shell: Tools → Site Health → Info → Media Handling. WordPress reports right there which ImageMagick version it is talking to and which Ghostscript version sits behind it. If the second one is missing, breathe.

Something that does not flatter the story is worth saying: a good share of those who escaped this escaped through a decision they never made. The policy.xml ImageMagick ships is deliberately open —the project says so itself: it is meant for controlled environments— but after the run of Ghostscript flaws in 2018 several distributions, Debian and Ubuntu among them, started packaging their own policy.xml with the PS, EPS, PDF and XPS coders set to rights="none", precisely because calling Ghostscript had stopped being considered safe. Anyone with that policy in place has had this particular path closed for years without knowing. It is a real defence, but let us call it by its name: it was not your foresight, it was inheritance.

Who holds the upload key

The second condition is the account. You need one with the upload_files capability, which in a default install means Author, Editor and Administrator —the Contributor role cannot upload files. When an advisory says "requires authentication", a lot of people read it as "requires being you". In a content management system it does not mean that. It means requires one of the accounts you hand out.

Think about the real corporate website, not the ideal one. The agency that built it in 2019 still has its user. The marketing person who used to upload press releases moved on in March. Last summer's intern was never deactivated. There is a membership plugin that assigns Author to anyone who signs up, because that is how it came configured. And there is a user called press whose password four people know, three of whom no longer work there. No attacker created any of those accounts: we did, one at a time, with a reasonable motive each time.

Ten minutes to find out if this is yours

What we would not do

Three common reflexes that end up costing you:

As of today there is no public record of this flaw being exploited. Yesterday we wrote about exactly how far that sentence goes: in the vCenter advisory it lasted five days. It helps you order the queue, not sleep soundly. With Ghostscript installed and Author accounts handed around, this one is for the afternoon.

If you take one thing away

Update to your branch's fixed release, check whether Ghostscript sits behind you, and clean up the list of people who can upload files. That settles this particular case. What updating does not settle is the other thing: your site calls libraries that call interpreters you never chose —the same problem we described with the library nobody chose in Rails— and each of them has its own idea of what the file you just handed over actually is. Which is why the question this advisory leaves behind is not "am I on 7.0.4?" but this one: how many accounts on your site can upload a file, and when did anyone last read that list all the way through?

Sources (consulted on 14 August 2026): release date, flaw description, credit to pwn.ai, the CVE-2026-65640 and GHSA-8vr3-7mxf-gx8w references and the scope of the backport through to the 4.7 branch — WordPress 7.0.4 release note; the 4.7 release date and the PDF thumbnail feature it introduced — version 4.7 documentation (connecting the two is our reading, not a statement from the project); severity, identifier, per-branch fixed versions and the description of the upload_files capability — INCIBE-CERT advisory INCIBE-2026-552; the content of the fix in WP_Image_Editor_Imagick::load() — commit 7daaa50 in wordpress-develop; upload paths that skip content inspection (XML-RPC and wp_upload_bits()) — analysis by Cyber Security News; the deliberately open nature of the policy the project ships — ImageMagick security policy; ways around the coder restrictions, published in March 2026 by the same team that reported this flaw — pwn.ai research. Neither WordPress nor INCIBE has published information about ongoing exploitation; any claim about specific campaigns today would be speculation. Photo: "Alphabet letterpress", public domain (CC0), via Openverse (rawpixel).