WordPress 7.0.4 Fixes CVE-2026-65640: What Site Owners Need to Do

WordPress 7.0.4 shipped on August 12, 2026 as a security-only release, and it fixes exactly one thing. CVE-2026-65640 is a remote code execution flaw that turns permission to upload a media file into the ability to run code on the server. The part worth understanding, and the reason a one-line "update now" post is not enough here, is that the dangerous path only exists on servers with a particular image-processing setup. How worried you should be depends less on WordPress than on what your host installed underneath it.

That makes CVE-2026-65640 an awkward one to judge from headlines. The official advisory scores it 8.8 out of 10 and rates it High. Patchstack's database entry, looking at the same bug, describes exploitation as unlikely for now. Both readings are defensible, and neither one tells you what to do about your site. This article covers what the bug actually is, the two conditions that both have to be true before it matters to you, how to check each one in a few minutes, and what your options are if you cannot update today.

TL;DR

• WordPress 7.0.4 fixes CVE-2026-65640 (GHSA-8vr3-7mxf-gx8w), an authenticated Author-level remote code execution issue reported by the team at pwn.ai. The advisory rates it High, CVSS 8.8.
• Everything from WordPress 4.7.0 through 7.0.3 is affected. The fix was backported to every branch back to 4.7.
• Two conditions must both hold for the code execution path to exist: the server uses Imagick and Ghostscript, and an attacker has an account with the upload_files capability, which by default means Author or above.
• Check your image stack under Tools → Site Health → Info → Media Handling, which lists the active editor along with ImageMagick, GD and Ghostscript versions.
• Update now, and do not fold this into your WordPress 7.1 planning. 7.1 arrives August 19 on a separate schedule.
• If you genuinely cannot update today, the long-documented ImageMagick mitigation is to deny the PostScript-family coders in policy.xml. It costs you PDF thumbnails.

What WordPress 7.0.4 actually contains

7.0.4 is a security release with a single disclosed fix, described by the WordPress security team as an authenticated Author-plus remote code execution issue via malicious file upload on sites that use Imagick and Ghostscript. It was reported by the team at pwn.ai and disclosed responsibly. The release was led by John Blackbourn, with input from Dennis Snell and Jeremy Felt.

The advisory identifiers are CVE-2026-65640 and GHSA-8vr3-7mxf-gx8w. The weakness class is CWE-434, unrestricted upload of a file with a dangerous type. The published CVSS v3 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, which scores 8.8 and lands in the High band. Read that vector in plain terms: reachable over the network, not technically difficult, needs a low-privilege account, needs nobody to click anything, and a successful attack compromises confidentiality, integrity and availability alike.

The affected range is unusually wide. Every branch from 4.7.0 up to and including 7.0.3 is listed as vulnerable, which is close to a decade of releases. As a courtesy, the project backported fixes to all of those branches, so sites pinned to an older major version have a patched release available rather than being told to jump majors under pressure. The exact patched version number differs per branch, and the advisory lists all of them.

That courtesy comes with a reminder the project repeats every time, and it is worth taking seriously: only the most recent version of WordPress is actively supported. A backport to 5.4 solves today's problem. It does not make 5.4 a reasonable thing to be running.

The fix also went into the WordPress 7.1 release candidate that was due the same day, so the 7.1 line carries it too.

How a media upload becomes code execution

WordPress can process images through two different PHP extensions. GD handles common raster work. Imagick is the PHP binding for ImageMagick and supports a much wider set of formats and operations. WordPress prefers Imagick when it is available: the wp_image_editors filter defaults to array( 'WP_Image_Editor_Imagick', 'WP_Image_Editor_GD' ), so Imagick is tried first and GD is the fallback. Most people never think about which one their site ended up with.

ImageMagick's breadth is the root of the problem. It reads far more than JPEG and PNG. It also opens PostScript, EPS and PDF, and it does not render those itself. It hands them to an external helper program, a delegate, and for the PostScript family that delegate is Ghostscript. Ghostscript is a full interpreter for a programming language, and it has a long history of being persuaded to do things it was never meant to do. This is the same family of problem as the ImageTragick bugs from a decade ago, and it is why several Linux distributions have shipped ImageMagick with the PostScript and PDF coders disabled by default since 2018.

Here is the mismatch that CVE-2026-65640 lives in. ImageMagick decides what a file is by looking at its contents. WordPress was deciding how to hand the file over based on its extension. Patchstack's analysis of the fix describes the vulnerable code precisely: WP_Image_Editor_Imagick::load() branched on the file extension alone and never inspected the bytes, so a file with an image extension whose contents were actually PostScript would be passed to Imagick, which would recognise what it really was and start Ghostscript.

The normal media upload flow was not the weak point. WordPress runs wp_check_filetype_and_ext() on uploads through the standard path, and that check catches this kind of mismatch. The gap was in the upload paths that skip it. Patchstack identifies the XML-RPC upload method and the cover-art extraction routine for uploaded MP3 files as two routes that write bytes to disk without inspecting them, after which the file could still reach the vulnerable code.

The patch closes it at the right place. According to Patchstack's read of the commit, load() now examines a file's real contents before an Imagick object is constructed, and refuses anything that would end up at a PostScript-family decoder. It rejects PostScript and EPS by signature as well as by extension, rejects files claiming to be PDFs that do not actually start with a PDF marker, and rejects compressed formats that ImageMagick would silently unpack. It also handles a subtler trick: ImageMagick lets a caller force a specific handler by prefixing the filename, so the new code strips and inspects those prefixes, while taking care not to mistake a Windows drive letter for one. The same validation is applied to filenames arriving from URLs and streams.

The design lesson underneath this is worth keeping even after you have updated. A file extension is a label the uploader chose. It is not a fact about the file, and any component further down the chain that sniffs content rather than trusting the label can disagree with your validation. That disagreement is where these bugs live.

Are you actually exposed? Two conditions, both required

The RCE path needs both of the following. If either is false on your site, the practical risk drops sharply, though you should still update.

Condition one: the server uses Imagick and Ghostscript

This is a server configuration question, not a WordPress setting, and most site owners have never checked it. The fastest way to find out is built into WordPress. Go to Tools → Site Health → Info and open the Media Handling section. It reports the active editor, the ImageMagick version, the GD version and the Ghostscript version. If the active editor is WP_Image_Editor_Imagick and a Ghostscript version is present, both halves of the precondition are in place.

If you have SSH access, you can check the same things directly:

wp eval 'echo extension_loaded( "imagick" ) ? "imagick: yes" : "imagick: no";'
gs --version

A "command not found" response to gs is a reasonable indication that Ghostscript is not installed for that user, though it is not conclusive on every hosting setup, since the binary can exist somewhere ImageMagick can find it but your shell path cannot. Site Health's Ghostscript line is the more reliable answer because it reflects what WordPress itself sees.

One caveat worth stating plainly rather than glossing over. Managed hosting platforms differ in whether Imagick, Ghostscript or both are present, and that can vary between plans, PHP versions and container images on the same provider. Do not assume based on your host's marketing. Check Site Health on the actual site.

Condition two: someone untrustworthy can upload media

The capability that matters is upload_files. In a default WordPress install, Administrators, Editors and Authors have it. Contributors and Subscribers do not. Plugins routinely change this. Membership plugins, LMS platforms, multi-vendor marketplace extensions, form plugins with file upload fields and custom role editors can all grant upload rights to roles you think of as low-privilege.

So the real question is not "do I have Authors" but "how many accounts on this site can put a file in the media library, and how confident am I in every one of them." For a two-person site with a locked-down user list, the answer is comfortable. For a multi-author publication, a client site with a long tail of freelancer accounts, a membership site with open registration, or anything where an account can be bought rather than granted, the bar is far lower than "Author-level" makes it sound.

Listing your users is a two-minute job over SSH:

wp user list --fields=ID,user_login,user_email,roles --format=table

Also worth remembering: an attacker does not need to be given an Author account. They need to end up with one. A reused password, a phished contributor, or a credential-stuffing hit on an old account gets them there, and this vulnerability is what converts that foothold from an annoyance into a server compromise. That is the honest reason the "authenticated" qualifier should not put you at ease.

Why the severity ratings disagree, and which one to act on

The GitHub advisory rates this High at CVSS 8.8. Patchstack's entry rates the practical impact as low and describes exploitation as unlikely at this time, given the privilege required, while still issuing a mitigation rule for its customers. That is a real disagreement, and both positions are reasonable.

CVSS is scoring the outcome and the mechanics. Low privileges required, no user interaction, full compromise of confidentiality, integrity and availability. Under those rules, 8.8 is what you get. Patchstack is scoring the likelihood on a typical WordPress site, where the attacker needs an account first and the server needs a specific image stack second. Two preconditions in series makes for a much smaller real-world target population than the score implies.

The mistake is treating either number as your answer. Your site is not the average. Both preconditions either hold for you or they do not, and you can determine that in five minutes with the checks above. A single-author brochure site on a GD-only stack is at the low end of the range no matter what CVSS says. A membership site with open registration on an Imagick and Ghostscript server is at the high end no matter what a vulnerability database says about likelihood.

At the time of writing, none of the published sources report in-the-wild exploitation of CVE-2026-65640. That is a genuinely reassuring fact and also the fact most likely to change, so treat it as a snapshot rather than a reason to defer. The disclosure details, including the commit, are public.

What to do now

Update. This is the whole fix, and everything below it is a distant second. If your site takes automatic background updates it may already be done, so verify rather than assume:

wp core version
wp core update

If you update through the dashboard, it is Dashboard → Updates → Update Now. If you are on an older branch, take the backported release for that branch rather than skipping majors under time pressure, then plan the major upgrade properly afterwards.

Verify the update actually applied. A site with a failed update, a locked filesystem or a stalled cron can sit on an old version while the dashboard implies otherwise. Check the reported version after updating, and check it on every site you manage rather than assuming a fleet-wide job succeeded everywhere.

If you cannot update immediately, there are two mitigations worth knowing, and both are genuinely worse than updating.

The first is the long-standing ImageMagick approach: deny the PostScript-family coders in ImageMagick's security policy file, so ImageMagick will not hand anything to Ghostscript at all. This is the same mitigation the distributions adopted after the 2018 Ghostscript issues, and the rules look like this:

<policymap>
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="PS2" />
  <policy domain="coder" rights="none" pattern="PS3" />
  <policy domain="coder" rights="none" pattern="EPS" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="XPS" />
</policymap>

The file location and the exact syntax depend on your ImageMagick major version and distribution packaging, so check ImageMagick's own security policy documentation for your version rather than copying a path from a blog post. The trade-off is concrete: WordPress uses Imagick with Ghostscript to generate PDF thumbnail previews, so denying the PDF coder means uploaded PDFs stop getting preview images. On a documentation-heavy or download-heavy site, someone will notice.

The second is to push WordPress to prefer GD, using a small must-use plugin:

<?php
/**
 * Plugin Name: Prefer GD Image Editor
 * Description: Puts GD ahead of Imagick in the WordPress image editor order.
 */
add_filter( 'wp_image_editors', 'wpuser_prefer_gd_editor' );

function wpuser_prefer_gd_editor( $editors ) {
    return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
}

Be clear-eyed about what this does and does not achieve. It changes which editor WordPress reaches for first, which reduces exposure to this particular code path, but it does not remove Imagick from the server and it does not stop any plugin that calls Imagick directly. GD also produces different output quality and supports fewer formats, and PDF thumbnails go away here too. Treat it as a stopgap for a site you genuinely cannot patch this week, not as a decision.

Review who can upload. Whether or not you were exposed, this is the right week to audit accounts with upload_files, remove dormant contributor and author accounts, and check whether any plugin has quietly granted upload rights to a role you assumed was read-only. If your site allows open registration, confirm what the default role can actually do.

Consider XML-RPC. One of the paths that reached the vulnerable code went through XML-RPC's upload method. If nothing on your site uses XML-RPC, disabling it removes an entry point you were not using anyway. Check first: the WordPress mobile apps, Jetpack, some publishing tools and pingbacks all depend on it, and turning it off blind creates a different support problem.

If you have reason to think a site was hit, treat it as a compromise investigation rather than an update task. Code execution means the attacker's foothold can outlive the patch, so look for new administrator accounts, unexpected files in wp-content/mu-plugins, modified core files and scheduled tasks you did not create. Restoring from a backup taken before the suspect period is often faster and more trustworthy than cleaning by hand.

Should you wait and roll this in with WordPress 7.1?

No. WordPress 7.1 is scheduled for August 19, 2026, and it is a major release with a genuinely large surface area of editor and admin changes that deserves a staging pass before it touches production. That is a different kind of decision, made on a different timeline, with different risks.

7.0.4 is a security-only release with a change confined to image handling. It is one of the lowest-risk updates you will apply this month, and there is no version of "let's batch these" that ends well. Apply it now, then plan 7.1 on its own merits.

There is also a scheduling wrinkle worth knowing about this specific week. WordCamp US runs August 16 to 19, with the 7.1 release landing on the closing day, so a lot of the people who normally answer compatibility questions will be at a conference or travelling home from one. Anything you want vendor input on is better raised now than on the 19th.

Frequently asked questions

Does CVE-2026-65640 affect my site if it uses GD instead of Imagick? The specific attack chain described in the advisory requires Imagick and Ghostscript on the server, so a GD-only site is not exposed to that path. Update anyway. Server stacks change without site owners being told, plugins can install or enable extensions, and a fixed WordPress version is the only state that stays safe when the environment underneath shifts.

Can an anonymous visitor exploit this? No. The advisory describes it as authenticated Author-level or higher, meaning the attacker needs an account with the upload_files capability before any of this becomes reachable. That is the reason vulnerability databases differ on likelihood. It is not a reason to relax if your site hands out accounts freely or has stale author accounts with weak passwords.

Which WordPress versions are affected and which are safe? Everything from 4.7.0 through 7.0.3 is listed as affected. WordPress 7.0.4 is the fixed release on the current branch, and backported fixes exist for every older branch back to 4.7. The advisory lists the patched version number for each branch, so check it against the exact version you are running rather than assuming.

How do I find out whether my server uses Imagick and Ghostscript? Go to Tools → Site Health → Info and expand Media Handling. It lists the active image editor along with the ImageMagick, GD and Ghostscript versions detected on the server. If you have SSH access you can confirm the same from the command line, but Site Health reflects what WordPress itself sees, which is the number that matters.

Should I disable PDF uploads to protect myself? That is not where the risk sits, and doing it would give false comfort. The issue was not that PDFs are allowed; it was that a file could carry PostScript content while wearing an image extension, so blocking one extension does not close the path. Update, and if you need a temporary server-level mitigation, deny the PostScript-family coders in ImageMagick's policy file instead.

Is there any sign of active exploitation? No public reports of in-the-wild exploitation had appeared at the time of writing. That is the fastest-moving fact in this article and should be re-checked against current advisories rather than relied on. Technical details of the fix are public, which historically shortens the gap between disclosure and attempts.

My host applies core security updates automatically. Do I need to do anything? Verify, then stop worrying. Automatic background updates cover minor security releases on most well-configured installs, but a site with a read-only filesystem, a broken cron, a version pinned by a deployment process or a plugin that disables updates can silently miss one. Checking the running version takes seconds and is the only way to know.

The takeaway

CVE-2026-65640 is a good reminder that a WordPress site's attack surface does not end at WordPress. The bug lived in the seam between what WordPress believed a file was and what ImageMagick decided it actually was, and its worst outcome depended on whether a completely separate program, Ghostscript, happened to be installed on the server. You could read the entire WordPress changelog and still not know your own exposure without looking at your image stack.

Update to WordPress 7.0.4, or to the backported release for your branch, and do it before you start planning for 7.1. Then spend ten minutes on the two questions this vulnerability raises that outlive it: who on your site can upload files, and do you actually know what your server does with the ones they upload.

If keeping on top of core security releases is the part that keeps slipping, that is exactly the work managed WordPress hosting is meant to absorb. MagicWP applies automatic core updates with rollback, runs malware scanning and a WAF in front of every site, keeps sites in isolated containers, and takes daily off-site backups with one-click restore, so a security release like this one is handled and verifiable rather than another item on your list. You can review the platform's security features and backup and restore options in the docs, and if you want to test a core update before it reaches production, one-click staging is part of every WordPress hosting plan.