Published on 13 August 2026
An uploaded image that isn't actually an image at all – and suddenly foreign code is running on your server. This is exactly the scenario that the WordPress security update 7.0.4 addresses. The vulnerability, tracked as CVE-2026-65640, allows logged-in users with at least the "Author" role to execute arbitrary program code on the web server via a malicious file upload (a so-called Remote Code Execution, or RCE for short). WordPress rates the issue as high and explicitly recommends updating affected websites immediately.
The good news first: not every WordPress installation is vulnerable. For the attack to work, several conditions must be met simultaneously. The less good news: precisely these conditions are quite often present on many typical SME websites – such as those with multiple editors, customer areas or membership portals. In this article, we explain in plain terms what happened, how to check whether you are affected, and which concrete steps you need to take now.
On 12 August 2026, WordPress released version 7.0.4 as a pure security release. It closes the vulnerability CVE-2026-65640. The official GitHub Security Advisory (GHSA-8vr3-7mxf-gx8w) rates the flaw with a CVSS score of 8.8 out of 10 ("High") – CVSS being the industry-standard scale for assessing the severity of security vulnerabilities.
The WordPress security team describes the flaw as follows:
"Authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript." – WordPress Security Team
Translated, this means: a logged-in user with at least the Author role can execute malicious code via a malicious file upload on websites that use the Imagick and Ghostscript components. WordPress itself puts it unambiguously:
"Because this is a security release, it is recommended that you update your sites immediately." – WordPress
According to the release announcement, the discovery was responsibly reported by pwn.ai. Backports – that is, follow-up fixes for older version lines – have also been published for older WordPress branches going all the way back to 4.7.
To understand why a harmless-looking image can become dangerous, it helps to take a look at two of the tools involved:
The core of the problem: WordPress partly handled an uploaded file based on its file extension (such as ".png"), while ImageMagick evaluates the actual content of the file. This discrepancy can be exploited. An attacker can disguise PostScript content so that it looks like an ordinary image. If that content then ends up with Ghostscript, a weakness in its handling of certain embedded files kicks in – and the path to code execution is clear.
In technical terms, the flaw is classified as CWE-434, i.e. "Unrestricted Upload of File with Dangerous Type". Dave Jong, Security Research Lead at Patchstack, sums it up:
"It changes how WordPress hands your uploaded media to ImageMagick, and it closes a path that could let a logged-in author turn an ordinary-looking image upload into code execution on your server." – Dave Jong, Patchstack
The applied patch (commit title: "Media: Prevent loading images into Imagick which might be PostScript") tackles exactly this point: in future, WordPress reads the file data before processing by Imagick and checks it. Rejected now are, among other things, PostScript formats and signatures, fake PDFs, compressed containers and forced Imagick format identifiers in the file name – the latter prevents an attacker from deliberately forcing a dangerous decoder.
Patchstack's analysis names as relevant upload paths, among others, the XML-RPC interface (wp.uploadFile) as well as the cover-art extraction from uploaded MP3 files. Important for context: this is not an anonymously exploitable flaw and it does not affect every WordPress installation. The prerequisites (login, upload permission, Imagick + Ghostscript) must come together.
In principle, all WordPress versions from 4.7.0 to 7.0.3 are vulnerable – but only if the following conditions are additionally met:
upload_files capability. By default, this belongs to the Author, Editor and Administrator roles.Particularly exposed are therefore websites with multiple authors: editorial teams, membership portals, customer areas or user accounts that have grown unwieldy over the years. Even a single compromised Author account is already enough. Those running a strictly administered single-editor setup without further upload accounts, on the other hand, have a considerably narrower set of attack prerequisites – but not zero.
Important: installations without the combination of Imagick and Ghostscript should also update, because the version itself falls within the affected range. Updating is the right decision in any case.
A reliable figure for concretely vulnerable or compromised installations has not been published. To put the prevalence into context: W3Techs determined on 12 August 2026 that WordPress runs on 41.0% of all websites – but this says nothing about the actual vulnerability to this specific CVE. At the time of research, there is no confirmed active exploitation of this flaw; it was not listed in the CISA KEV catalogue. However, this is no free pass: experience shows that public exploits often appear after a patch is released.
wp core version. Any version below the appropriate patch level needs updating.php -m | grep -i imagick shows whether the PHP extension is active. Alternatively, your host can confirm this authoritatively.gs --version or your host. If the command is not available, that alone does not prove that Ghostscript is absent – especially in managed hosting environments, the provider should give you information. What matters is the actual simultaneous use of Imagick and Ghostscript.upload_files capability, not the role name alone.upload_files to the bare minimum. Disable or block unused Author/Editor accounts and pay particular attention to external authors, former service providers and custom roles. This lowers the attack surface, but does not replace the patch.policy.xml). This is a supplementary safeguard, not a substitute for the WordPress update.A remote code execution is not automatically a reportable data breach. However, if, as a result of exploitation, personal data is accessed, exfiltrated, altered, encrypted or rendered inaccessible without authorisation, this may constitute a breach of confidentiality, integrity or availability.
Art. 32 GDPR requires technical and organisational measures appropriate to the risk – this includes the timely installation of security updates as well as regular effectiveness reviews. In the event of a data breach, Art. 33 GDPR applies: the competent supervisory authority must be informed without undue delay and, where feasible, within 72 hours of becoming aware, provided the breach is likely to result in a risk to the rights and freedoms of natural persons. Every data breach must be documented. Where a high risk is likely, Art. 34 GDPR generally also requires the affected individuals to be notified without undue delay.
A breach of Art. 32 falls, under Art. 83(4) GDPR, into the fine range of up to EUR 10 million or 2% of the total worldwide annual turnover of the preceding year – whichever is higher. The concrete amount depends on factors such as severity, duration, culpability, mitigation of damage, measures taken and cooperation. In addition, in the case of material or non-material damage, a claim for damages may arise under Art. 82 GDPR.
In short: anyone who now patches promptly and documents the process fulfils not only a security-related duty but also a legal duty of care.
CVE-2026-65640 is, at CVSS 8.8, a serious vulnerability that can have full impact on confidentiality, integrity and availability. It is, admittedly, tied to several prerequisites – login, upload permission and the combination of Imagick and Ghostscript – but this is precisely the constellation that is a reality on many SME websites. A single compromised Author account can be enough.
The recommended course of action is clear: update WordPress without delay to 7.0.4 or the appropriate patch level of your branch, reduce unnecessary upload permissions and ensure a reliable update process. Even though no active exploitation is confirmed at the time of research – that can change quickly after a patch release. Those who act today are on the safe side.