Quick answer: WordPress 7.0.4 is an urgent security release published on August 12, 2026. It patches a high-severity remote code execution vulnerability involving malicious PostScript uploads on servers using both Imagick and Ghostscript. An attacker must already have an account with the upload_files capability—normally Author level or higher—but affected sites should still update immediately.[6][7]
Do this now: 8-step WordPress 7.0.4 checklist
- Open Dashboard → Updates and record the installed WordPress version.
- Create a fresh backup of the database and site files, and confirm that you know how to restore it.
- Update WordPress core to 7.0.4. If the site intentionally remains on an older branch, install that branch’s patched backport instead.[7][8]
- Update active plugins and themes, then clear page, object, CDN and browser caches.
- Verify the installed version in Dashboard → Updates or with
wp core version. - Test login, media uploads, the editor, forms, search, checkout and other business-critical flows.
- Review user accounts with Author, Editor or Administrator access; remove stale accounts and reset credentials where appropriate.
- Review web, PHP and security logs for unexpected uploads or image-processing errors. Installing the patch closes the vulnerability but does not prove that an already exposed site was never targeted.
Who is affected by CVE-2026-65640?
The official advisory says exploitation requires both Imagick and Ghostscript on the server plus a malicious authenticated user who has upload_files. WordPress commonly grants that capability to Authors and higher roles, although plugins and custom role settings can change permissions.[7]
| Check | Verified answer |
|---|---|
| Vulnerability | Remote code execution through a malicious PostScript file upload.[7] |
| Severity | High.[7] |
| Access required | An authenticated user with upload_files, described by WordPress as Author level or higher.[6][7] |
| Server prerequisites | Imagick and Ghostscript must both be in use.[7] |
| User interaction | None after the malicious user can upload the file.[7] |
| Patched current version | WordPress 7.0.4.[6][7] |
| Older branches | Patched releases are available back through WordPress 4.7; WordPress 4.6 and earlier do not receive this fix.[7][8] |
Important: A site that does not meet both server prerequisites has a lower exposure to this specific flaw, but that is not a reason to remain on a vulnerable WordPress build. The official release announcement recommends updating immediately.[6]
Patched versions by WordPress branch
Use the newest available WordPress version whenever possible. If a compatibility constraint temporarily keeps a site on an older branch, the advisory lists these fixed versions:[7][8]
| Branch | Patched version | Branch | Patched version |
|---|---|---|---|
| 7.0 | 7.0.4 | 6.9 | 6.9.7 |
| 6.8 | 6.8.8 | 6.7 | 6.7.7 |
| 6.6 | 6.6.7 | 6.5 | 6.5.10 |
| 6.4 | 6.4.10 | 6.3 | 6.3.10 |
| 6.2 | 6.2.11 | 6.1 | 6.1.12 |
| 6.0 | 6.0.14 | 5.9 | 5.9.16 |
| 5.8 | 5.8.15 | 5.7 | 5.7.17 |
| 5.6 | 5.6.19 | 5.5 | 5.5.20 |
| 5.4 | 5.4.21 | 5.3 | 5.3.23 |
| 5.2 | 5.2.26 | 5.1 | 5.1.24 |
| 5.0 | 5.0.27 | 4.9 | 4.9.31 |
| 4.8 | 4.8.30 | 4.7 | 4.7.35 |
WordPress says only the most recent version is actively supported, and versions 4.6 and earlier no longer receive security updates.[8]
How to check for Imagick and Ghostscript
WordPress dashboard method
Go to Tools → Site Health → Info → Media Handling and look for Imagick/ImageMagick details. Hosts expose different fields, so the absence of a clear value is not definitive. Ask the hosting provider whether WordPress image processing invokes both Imagick and Ghostscript.
WP-CLI and shell checks
Run these only if you have authorized shell access:
wp core version
wp eval 'echo extension_loaded("imagick") ? "Imagick loaded\n" : "Imagick not loaded\n";'
command -v gs && gs --version
The first command verifies WordPress core, the second checks whether PHP loads the Imagick extension, and the third checks whether a Ghostscript executable is available in the shell environment. Containerized or restricted hosting can make shell output differ from the PHP runtime, so confirm uncertain results with the host.
Safe update procedure
1. Back up and stage
Create a database dump and files backup before changing production. For stores, membership sites and other transactional sites, account for orders or submissions created between backup and cutover.
2. Patch WordPress core
Use Dashboard → Updates → Update Now, or use WP-CLI:
wp core update
wp core version
wp core verify-checksums
The official release documentation identifies /wp-includes/class-wp-image-editor-imagick.php as the revised application file and says no package was revised.[8]
3. Run a focused smoke test
Test these paths after the update:
- home page and important landing pages
- wp-admin login and role-based access
- JPEG, PNG and WebP uploads
- thumbnail and image-size generation
- post editing and publishing
- forms, checkout and payment callbacks
- scheduled jobs and email delivery
- REST API or mobile-app workflows
4. Review access and logs
Because the published prerequisites include an authenticated user with upload capability, audit Author, Editor and Administrator accounts. Check for unfamiliar users, unexpected role changes, unusual media uploads and image-processing errors. Escalate suspicious findings to the hosting or incident-response team rather than deleting evidence.
Does WordPress 7.1 include the fix?
Yes. WordPress states that the fix was included in WordPress 7.1 RC3, while the final WordPress 7.1 release remains scheduled for August 19, 2026.[3][6] Do not install a release candidate on a production site merely to obtain this fix; install WordPress 7.0.4 or the patched release for your current stable branch.[3]
Related: WordPress 7.0.3 security update checklist.
FAQ
Is WordPress 7.0.4 a feature update?
No. It is a targeted security release. The official documentation lists one revised WordPress application file and no revised package.[8]
Can an unauthenticated visitor exploit this vulnerability?
The published advisory describes a malicious authenticated user with the upload_files capability as a prerequisite. It does not describe an unauthenticated attack path for this CVE.[7]
Is updating enough after a suspected compromise?
No. Updating prevents future exploitation through the patched flaw, but a suspected compromise requires log preservation, account review, file and database integrity checks, credential rotation, and incident-response analysis.
What if automatic updates are enabled?
WordPress says supported sites will begin updating automatically, but administrators should verify the installed version rather than assume the update completed.[6]
Should I disable Imagick or Ghostscript instead of updating?
No. Changing media tooling may reduce exposure to this specific attack path, but the supported remediation is to install a patched WordPress version. Any server-level change should be coordinated with the host because it can affect uploads and thumbnail generation.[7]
Sources
[3] https://make.wordpress.org/core/2026/08/12/wordpress-7-1-release-candidate-3 — WordPress 7.1 Release Candidate 3
[6] https://wordpress.org/news/2026/08/wordpress-7-0-4-release — WordPress 7.0.4 Release
[7] https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-8vr3-7mxf-gx8w — CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w advisory
[8] https://wordpress.org/documentation/wordpress-version/version-7-0-4 — WordPress 7.0.4 documentation