WordPress 7.0.4 security release: what site owners need to know

WordPress 7.0.4 fixes one security issue: an authenticated Author-or-higher remote code execution vulnerability involving malicious file uploads on sites that use Imagick and Ghostscript. The fix matters, but the conditions matter too.

What WordPress 7.0.4 fixes

WordPress 7.0.4 was released on August 12, 2026 as a focused security release. Unlike 7.0.3, which addressed a broader set of security issues, 7.0.4 contains one disclosed fix: authenticated Author+ remote code execution through a malicious file upload on sites using Imagick and Ghostscript.

The vulnerability was responsibly reported by the team at pwn.ai. The public advisory is tracked as CVE-2026-65640 and GHSA-8vr3-7mxf-gx8w.

What “authenticated Author+ remote code execution” means

“Remote code execution” is the part of the description that naturally gets attention because, in a successful exploit, it can allow attacker-controlled code to run on the server. But the rest of the description is equally important when judging practical risk.

WordPress describes this issue as authenticated Author+. In other words, the reported attack path requires an existing WordPress account with at least the Author role. It is not described as an unauthenticated vulnerability that any anonymous visitor can trigger directly.

That distinction materially changes the exposure for a typical company website where only a small number of trusted administrators can log in. It matters more on publishing, editorial, membership, community, or other sites that deliberately give Author-level access to a larger group of people.

Why Imagick and Ghostscript matter

The official release also narrows the affected scenario to sites that use Imagick and Ghostscript. These are commonly used server-side tools for processing images and document formats.

The WordPress 7.0.4 changelog shows that the Core change is confined to wp-includes/class-wp-image-editor-imagick.php, with no package revisions. That lines up with the image-processing scope described in the security notice rather than indicating a broad change across WordPress Core.

So the practical risk is not identical across every WordPress installation. It depends on both the permissions available to logged-in users and the server-side image-processing stack. That is useful context, but it is not a reason to ignore the update: the supported fix is available, and installing it removes the known vulnerable path.

Does this mean WordPress is insecure?

A security release should be taken seriously without turning it into evidence that WordPress is uniquely unsafe. WordPress is one of the most widely deployed web platforms in the world, which also means its code receives sustained attention from security researchers, hosting companies, developers, and the wider open-source community.

Widely used software will have vulnerabilities discovered over time. A healthier security signal is that issues are responsibly reported, fixed, disclosed, and distributed to users. For site owners, the practical lesson is less dramatic: keep Core, plugins, themes, PHP, and the surrounding hosting stack maintained, and avoid leaving old unsupported versions in production indefinitely.

Which sites deserve extra attention?

Based on the conditions described in the official release, I would pay particular attention to sites that:

• give Author or higher roles to people outside a small trusted team
• run editorial or community workflows with many content contributors
• allow those users to upload media as part of their normal workflow
• use Imagick and Ghostscript on the server
• have unknown, old, or unnecessary Author-level accounts

A small brochure or WooCommerce site with only trusted Administrator accounts has a different exposure profile from a multi-author publishing platform. Both should update, but the second deserves more attention to user access and upload history.

How to update WordPress 7.0.4 safely

1. Take a current backup. Back up both files and database before changing Core on a production site.
2. Install the security release. Update through Dashboard → Updates, WP-CLI, or your normal deployment workflow.
3. Confirm the installed version. Do not assume an automatic background update completed successfully.
4. Test the frontend and wp-admin. Check important pages, login, editing, and media uploads.
5. Test business-critical workflows. On WooCommerce or membership sites, verify checkout, payments, subscriptions, forms, and integrations.
6. Review unexpected errors. Check PHP and server logs if anything behaves differently after the update.

What about older WordPress versions?

WordPress has now released corresponding security updates for affected branches from 6.9 back through 4.7. For example, 6.9 received 6.9.7, 6.8 received 6.8.8, and 4.7 received 4.7.35. WordPress 4.6 and earlier no longer receive security updates.

The fix is also being included in WordPress 7.1 RC3. The project repeats an important point in the 7.0.4 documentation: only the most recent WordPress version is actively supported. Backports are useful for sites that cannot move immediately, but they should not be treated as a reason to keep a very old WordPress branch indefinitely.

WordPress 7.0.3 vs 7.0.4

The two releases are close together in time but address different security problems. WordPress 7.0.3 fixed 12 issues across several areas of Core. WordPress 7.0.4 is narrower and fixes this specific Author+ remote code execution path.

Updating to 7.0.3 therefore is not a substitute for installing 7.0.4. You can read the earlier WordPress 7.0.3 security update guide for the previous release.

Should you investigate the site after updating?

For most normal sites, installing the patch and verifying the site is working is the appropriate response. There is no reason to assume a site was compromised simply because it was running a vulnerable version.

A deeper review becomes reasonable when the site has a broader Author-level user base and there are additional warning signs: unfamiliar accounts, unexpected file changes, unusual uploads, redirects, spam content, or server alerts. In that situation, our guide on how to tell if WordPress has been hacked provides a useful first-pass checklist.

If there are actual indicators of compromise, WordPress malware removal should focus on evidence and root cause rather than assuming this particular vulnerability was responsible.

FAQ

The practical takeaway

WordPress 7.0.4 is a security update and should be installed promptly. At the same time, the official description gives useful context: the disclosed issue requires Author-or-higher access and a specific image-processing setup involving Imagick and Ghostscript.

That makes this a good example of why security advisories should be read precisely. Patch the known issue, verify the update, review user access where the conditions apply, and avoid turning every security release into evidence that a platform is fundamentally unsafe.