WordPress released version 7.0.4 on August 12, patching a real remote code execution vulnerability. If your site runs Imagick and Ghostscript for image processing and has any user accounts at Author level or above, this one is worth actually reading, not skimming past.
What the vulnerability actually is
According to the official WordPress 7.0.4 release announcement, the fix addresses an authenticated remote code execution flaw triggered through a malicious file upload on sites using Imagick alongside Ghostscript. It’s tracked as CVE-2026-65640 (GHSA-8vr3-7mxf-gx8w), reported by the pwn.ai team.
The “authenticated” part matters for scoping the risk correctly. This isn’t an anonymous, drive-by attack path. An attacker needs an account with Author-level permissions or higher on the site already, whether that’s a legitimate compromised login or an intentionally malicious contributor. Once they have that, uploading a crafted file through Imagick’s processing pipeline is enough to get code execution, which is about as bad as a vulnerability gets.
Who this actually affects
Two conditions both need to be true for this to matter to your site:
- Imagick is your active image processing library (not every host or configuration uses it, some fall back to GD instead)
- Ghostscript is installed and available to Imagick on the server
If either of those isn’t the case, this specific CVE doesn’t apply to you directly, though updating core promptly is still the right move regardless. If you’re not sure which image library your site is using, that’s worth checking rather than guessing, since it changes whether this is an urgent fix or a routine one.
What to do about it
Update to 7.0.4. WordPress.org notes three ways to do it: download the update directly, use the Dashboard’s Updates screen, or let it happen automatically if your site has background updates enabled for minor releases. Most managed WordPress hosts push this kind of security release automatically within a day or two, but “probably already updated” isn’t the same as confirming it, especially on a site where an Author-level account might belong to someone outside your immediate team.
Worth a second check while you’re in there: review who actually holds Author-or-above roles on the site. A vulnerability that requires that level of access is only as risky as the accounts that have it, and it’s common for old contributor or guest-author accounts to sit around long after anyone’s using them.
This kind of release, quick core patch, narrow but real attack path, is exactly the sort of thing that’s easy to miss if nobody’s specifically watching for it. Ongoing WordPress development and maintenance work catches this category of update as a matter of course rather than something that gets noticed a month later during an audit.
