WordPress 7.0.4 closes a remote code execution hole in the media library
Released on , WordPress 7.0.4 is a single-issue security release that patches an authenticated remote code execution flaw on sites running Imagick and Ghostscript. Read the WordPress.org release note here.
There is no feature load in this release. WordPress 7.0.4 ships one patch, and the release note asks site owners to update immediately rather than wait for a convenient window. The vulnerability is catalogued as CVE-2026-65640, carries a CVSS v3 base score of 8.8 (High), and was reported by the team at pwn.ai through the project's responsible disclosure process. The release was led by John Blackbourn, with input from Dennis Snell and Jeremy Felt.
What makes this worth a client briefing rather than a silent background update is the breadth of the backport. The fix has been carried back through every branch to 4.7, which means two dozen separate WordPress versions were patched on the same day. That is the project signalling that a meaningful share of the installed base is exposed, not just sites sitting on the current major version. The full technical write-up is in the project's GHSA-8vr3-7mxf-gx8w advisory.
How it works
This is a file upload vulnerability, classified as CWE-434, unrestricted upload of file with dangerous type. The exploit chain has three links, and all three have to be present before a site is genuinely at risk.
First, the server has to be running Imagick with Ghostscript available. Imagick is the PHP extension that wraps ImageMagick, and WordPress will use it in preference to GD when it is installed. ImageMagick does not decode PostScript or PDF files itself: it hands them off to Ghostscript as a delegate. That handoff is where the weakness sits. The underlying flaw is in Ghostscript's handling of certain embedded files, not in WordPress's own upload code, which is why the same class of issue has surfaced across other applications that lean on the same delegate chain.
Second, an attacker needs a genuine account carrying the upload_files capability. In a default WordPress role map that means Author or above. This is not an unauthenticated, internet-wide exploit, and the distinction matters when you are triaging which sites to patch first.
Third, the attacker uploads a crafted PostScript file through the media library. WordPress passes it to Imagick to generate a preview, Imagick delegates the render to Ghostscript, and the embedded payload executes on the server with the privileges of the web server process.
The CVSS vector reads AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. In plain English: reachable over the network, low attack complexity, low privileges required, no interaction needed from a victim, and total loss of confidentiality, integrity and availability once it succeeds. The only factor holding the score below critical is the account requirement.
Where the real exposure sits
The account requirement is doing a lot of work in most people's mental model of this bug, and it is worth pressure-testing. An Author account is not a high-trust credential on the majority of content sites. It is the account you hand to a freelance writer for a three-month campaign, the one a membership plugin provisions automatically on signup, and the one that gets left in place when a contributor stops writing.
Consider a typical multi-author editorial site. Ten or fifteen Author accounts, several dormant, most protected by a password the site owner has never seen and no second factor. Before this patch, a credential stuffing attack against one of those accounts bought an attacker the ability to publish a spam post. After it, on a server with Imagick and Ghostscript, the same compromised account buys arbitrary code execution and everything that follows: database access, credential theft from wp-config.php, persistence via a dropped web shell, and lateral movement to other sites sharing the same account on the host.
The second scenario is the one that catches agencies. A site with open or semi-open registration where the role has been escalated above Subscriber for a legitimate product reason, such as a community submission workflow or a directory listing where members upload their own images. In that configuration the attacker does not need to compromise anything. They register.
Worth noting is how ordinary the vulnerable server configuration is. Imagick with Ghostscript is a common default on shared hosting because it is what generates thumbnail previews for PDF uploads, a feature most hosts enable because clients expect PDFs to look like documents in the media library rather than generic file icons. Plenty of site owners are running this stack without ever having chosen it.
What this means for UK site owners
For a single site with background updates enabled, this is close to a non-event. WordPress applies security releases automatically by default, so most sites moved to 7.0.4 within hours of the announcement without anyone touching anything. Confirm the version in your dashboard and you are finished.
The work lands on anyone running an estate. If you manage twenty or two hundred WordPress sites, the questions are which of them have automatic updates disabled, which are pinned to an old branch by a plugin or theme dependency, and which sit on hosts that patch at the platform layer versus expecting you to do it. That inventory is the deliverable here, not the update itself, and it is the reason ongoing WordPress maintenance is priced as a retainer rather than a one-off. This is the second security release in six days, following WordPress 7.0.3 on 5 August, and the cumulative cost of manual review across an estate is what quietly turns into deferred patching.
There is a UK-specific dimension that is easy to skip past. A successful remote code execution on a site holding customer records is not merely a security incident, it is very likely a personal data breach under UK GDPR. Where that breach poses a risk to people's rights and freedoms, the controller has 72 hours from becoming aware of it to notify the Information Commissioner's Office. The practical consequence is that an unpatched Author-level RCE on a site with a customer database is a regulatory exposure sitting alongside the technical one, and the clock starts when you find out, not when you finish investigating.
Practical considerations
Do not spend long trying to establish whether a given server is genuinely vulnerable before patching. Determining whether Imagick is active and whether the Ghostscript delegate is registered takes longer than applying a single-issue core update, and the answer only describes today's configuration. Hosts change image processing libraries during migrations and PHP upgrades without telling anyone.
If you run sites on older branches, verify you received the right backport rather than assuming coverage. The patched releases run from 7.0.4 down through 6.9.7, 6.8.8, 6.7.7 and onwards to 4.7.35. Check the actual version string against the advisory. It is also worth being clear-eyed about what those backports mean: the WordPress project describes them as a courtesy and continues to state that only the most recent version is actively supported. A site on 5.4 that received a patch this week has not become supported software.
Sites deploying core from version control are the most likely to be quietly missing this. Background updates cannot write to a repository-managed core directory, so the update has to move through the normal deployment pipeline, which means it is subject to whatever review and release cadence that pipeline imposes. That is usually a good thing and occasionally, as this week, it is the reason a security patch waits behind a sprint boundary.
One last note on timing: the fix also shipped in the 7.1 release candidate, and 7.1 is now close. If you have been holding a site back from 7.0.x while waiting for the next major release, the sensible move is still to take 7.0.4 now and plan the 7.1 upgrade separately on its own testing schedule.
FAQ
Do I need to update if my site does not use Imagick or Ghostscript?
The exploit chain needs both Imagick and Ghostscript present on the server, so a site without them is not exploitable through this specific route. You should still update. Most site owners do not control which image libraries their host enables, hosts change that configuration without notice, and 7.0.4 is a single-issue release with a very small regression surface. Treating probably not affected as no action needed is how sites end up unpatched six months later.
Can an anonymous visitor exploit this?
No. The attacker needs a working account with the upload_files capability, which in a default role map means Author, Editor or Administrator. That is why the CVSS score is 8.8 rather than a full 10. The practical risk is that it upgrades a compromised or malicious low-tier account from a nuisance into full server-side code execution.
My site runs WordPress 6.8, not 7.0. Am I covered?
Yes, provided you take the update. The fix was backported to every branch as far as 4.7, so the patched releases include 6.9.7, 6.8.8, 6.7.7, 6.6.7, 6.5.10 and so on down the line. Check the version string in your dashboard against the patched list in the advisory rather than assuming your branch was included. The WordPress project describes these backports as a courtesy and states that only the most recent version is actively supported.
Will automatic background updates handle this for me?
For most sites, yes. WordPress applies minor and security releases automatically by default, so sites with background updates enabled will have moved to 7.0.4 shortly after release. The exceptions worth checking are sites where a host, a security plugin or a wp-config.php constant has disabled automatic updates, and sites running a version-controlled deployment where core is deployed from a repository rather than updated in place.
How do I check whether my server uses Imagick and Ghostscript?
Site Health under Tools in the WordPress admin reports which image processing library is active. For a definitive answer, ask your host, or check phpinfo() for the Imagick extension and whether the Ghostscript delegate is registered. Bear in mind that this tells you today's configuration. It is not a guarantee about next month's.
Two WordPress security releases in under a week. Is something wrong?
Not especially. 7.0.3 on 5 August and 7.0.4 on 12 August are unrelated, and a short gap usually reflects independent researchers reporting separately rather than a botched earlier fix. The pattern worth acting on is operational, not technical: if your process is to review each release by hand before applying it, two releases in six days is exactly the workload that causes a patch to be quietly deferred.
