Barely a day after WordPress 7.0.3 shipped fixing twelve vulnerabilities, WordPress pushed out 7.0.4 last night with a fix for a remote code execution bug of its own. That’s three security releases on WordPress core in under a month, following wp2shell in mid-July and 7.0.3 earlier this week. If you’re a Bangkok or Thailand business running WordPress, the pace of these releases matters as much as any individual bug, and 7.0.4 is worth understanding rather than just clicking update and moving on.
What’s actually in WordPress 7.0.4
Unlike 7.0.3, which patched twelve separate issues across core, 7.0.4 is a narrow, single-purpose release. It fixes one vulnerability, tracked as CVE-2026-65640 (GHSA-8vr3-7mxf-gx8w), an authenticated Author-level-or-higher remote code execution flaw triggered through a malicious file upload on sites that run Imagick together with Ghostscript for image processing. The public advisory rates it High severity with a CVSS score of 8.8 out of 10.
In plain terms, a user with Author-level access or above, not necessarily an Administrator, could upload a specially crafted file that gets processed by Imagick and Ghostscript in a way that hands them code execution on the server. Only one file was touched in the fix, wp-includes/class-wp-image-editor-imagick.php, which is why this shipped as such a tightly scoped release rather than a broader core update.
Who found it, and why that keeps happening
The vulnerability was responsibly reported by pwn.ai, the same AI-focused security research outfit credited alongside Anthropic and Aikido Security for several of the twelve fixes in 7.0.3 earlier this week. That is not a coincidence. AI-assisted vulnerability research is now producing findings on WordPress core at a pace the traditional patch cycle was not really built around, and the community reaction across the usual security and WordPress discussion channels has split along predictable lines, some treating this as further proof that AI tooling is outpacing WordPress core’s own defenses, others pointing out that an Author-level prerequisite meaningfully narrows who can actually pull this off.
Both things are true at once. Patchstack’s own database entry on the bug rates real-world exploitation as unlikely for now given the privilege required, but still issued a mitigation rule immediately rather than waiting to see if that held up.
Which versions are affected
This is not limited to the 7.x branch. The flaw affects every WordPress version back to 4.7, and fixed point releases have already shipped across the board: 7.0.4, 6.9.7, 6.8.8, 6.7.7, 6.6.7, 6.5.10, 6.4.10, 6.3.10, 6.2.11, 6.1.12, 6.0.14, 5.9.16, 5.8.15, 5.7.17, 5.6.19, 5.5.20, 5.4.21, 5.3.23, 5.2.26, 5.1.24 and 5.0.27. Sites still running 4.6 or earlier get nothing, those branches stopped receiving security updates entirely, which is its own argument for not leaving a WordPress install untouched for years. The fix is also included in WordPress 7.1 RC3, due the same day as this release, so it won’t need a separate patch when 7.1 ships.
How to check if you’re actually exposed
Your real exposure comes down to two things: whether your server uses Imagick with Ghostscript for image handling, and whether you have Author-level or higher accounts you don’t fully control. You can check the first under Tools → Site Health → Info → Media Handling in wp-admin, which lists your active image editor along with ImageMagick, GD and Ghostscript versions.
A single-admin brochure site with no outside contributors is low risk here. A hotel blog with several marketing staff logging in, an ecommerce store with guest authors, or an agency managing logins across multiple client sites, all common setups across Thailand, should treat this as more urgent, since Author roles get handed out more liberally than site owners usually realize.
What to actually do about it
- Confirm you’re on WordPress 7.0.4 or the matching point release for your branch, don’t assume automatic background updates already caught it.
- Check Site Health → Media Handling to see if Imagick and Ghostscript are active on your server. If they’re not, your practical exposure is much lower, but you should still update.
- Audit who has Author access or above. Former staff, guest contributors, and old client logins are the accounts most likely to get overlooked.
- Don’t wait for 7.1. This fix is included in 7.1 RC3, but 7.1 itself isn’t due until August 19, this patch needs to go in now, on your current version.
- Keep tested, offsite backups as a baseline, RCE vulnerabilities are exactly the scenario a fast rollback exists for.
How we handle this for our Clients in Thailand
At Sierra IT Group, releases like 7.0.4 are exactly why we run ongoing WordPress maintenance packages rather than leaving updates to chance. Every site we manage gets core, plugin and theme updates applied promptly, with monitoring and tested backups in place before anything changes. Our fully managed WordPress hosting adds hardened server configurations and firewall rules on top, and if a site has already been compromised, our malware removal and recovery team gets it cleaned up and back online fast. If you’re not sure whether your current setup is exposed, get in touch and we’ll check it for you.