The short version
WordPress 7.0.4, released 12 August 2026, fixes one vulnerability: CVE-2026-65640, an authenticated Author-level remote code execution affecting sites that run ImageMagick alongside Ghostscript. It arrived six days after WordPress 7.0.3, which fixed twelve separate issues. Both are security releases. Update now, and verify the version yourself rather than assuming background updates ran.
- 7.0.4 — 12 August 2026. One flaw, CVE-2026-65640. A contributor with an Author account could upload a file named like an image that was actually a program, and get it executed on the server. Present in core since version 4.7 — close to nine years.
- 7.0.3 — 6 August 2026. Twelve fixes, including a pre-authentication cross-site scripting flaw on the login screen (CVE-2026-64638) with the potential to reach PHP code execution.
- Not every site is exposed to the 7.0.4 flaw. It requires the server to have ImageMagick wired to Ghostscript, and an attacker who already holds an Author account or better. There is a tested way to check further down this page.
- The timeline is the real story. Three security releases inside five weeks, with AI-assisted research credited on the most serious findings in each.
What WordPress 7.0.4 actually fixes
The official release note is one sentence long: an “authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript,” reported by the team at pwn.ai. That sentence hides a genuinely elegant bug, and the mechanism is worth understanding because the same shape of mistake appears in almost every file-upload system ever built.
A .png that is not a .png
WordPress uses ImageMagick, through the Imagick PHP extension, to resize and process media. ImageMagick handles far more than JPEG and PNG — it also opens PostScript, EPS and PDF, and to render those it calls out to Ghostscript, a program with a long and well-documented history of being persuaded to run commands it should not.
The mismatch sits between two different ideas of what a file is. ImageMagick decides by reading the first few bytes — the file’s actual contents. WordPress was deciding by reading the filename. So a file called holiday.png, whose bytes actually begin with a PostScript signature, cleared the upload check as an image, reached ImageMagick, which recognised the PostScript inside, and handed it to Ghostscript to execute.
In code, the vulnerable method was WP_Image_Editor_Imagick::load(), which selected how to hand a file to ImageMagick based only on the extension and never looked inside. That analysis comes from Patchstack’s security team, who documented the flaw the same day the release shipped; WordPress’s own note stays deliberately brief while sites patch.
Why the Author gate is lower than it sounds
This is not a drive-by. An attacker needs to be able to add media, which means an Author-level account or higher. On a two-person business site, that is a small and trusted group, and your exposure is genuinely low.
On a multi-author publication, a membership site, a site with guest contributors, or an agency-run site with a dozen client logins, the picture changes. One compromised or careless author account stops being a defaced post and becomes code running on your server. If you hand out accounts beyond a core team, treat this as urgent rather than routine.
The two doors that skip the check
WordPress does have a defence here. On a normal upload, wp_check_filetype_and_ext() inspects the file and catches exactly this kind of name-versus-contents mismatch. If every route into the Media Library went through it, the flaw would be much harder to reach.
Two routes do not, according to Patchstack’s analysis: XML-RPC’s wp.uploadFile method, and the cover-art extraction routine that runs on uploaded MP3s. Both write bytes using a lower-level function that never inspects content. XML-RPC is enabled by default and reachable without ever touching an admin screen, which is what turns a theoretical mismatch into a usable path.
The risky moment in any media pipeline is the gap between what a file is named and what it actually contains.
What 7.0.3 fixed six days earlier
The 6 August release was the broader one: twelve vulnerabilities across cross-site scripting, privilege escalation, information disclosure, CSS injection, an email verification bypass and server-side request forgery. Here is the complete list from WordPress’s own release note, with the access an attacker would need for each.
| Issue | Access required | Reported by |
|---|---|---|
| Reflected XSS on the login screen, with potential to lead to PHP code execution (CVE-2026-64638) | None — pre-auth | pwn.ai |
| Stored XSS in posts via the emoji settings element | Contributor+ | Asaf Mozes (amosec) |
| Stored XSS in the Post Content block | Contributor+ | N05ec@LZU |
| Stored XSS in Quick Edit on sites with many users | Contributor+ | Naveen S and Ajmal Moochingal |
| Stored XSS in the Post Date block | Contributor+ | Alex Concha, WordPress Security Team |
| Privilege escalation letting a user create a new site | Registered user, multisite only | Aikido Security |
| Latest Comments block exposing comments on password-protected posts | None | Ehtisham Siddiqui, WordPress Security Team |
| Enumeration of post slugs | None | HDWSec |
| Disclosure of notes in comment feeds | None | Elio Gubser |
| CSS injection via a bypass of the safe CSS attribute filter | Author+ | Anthropic |
| Bypass of the email address confirmation flow | None | Omar Hasan |
| SSRF in URL validation allowing requests to link-local ranges | None | Andrew Mohawk and multiple independent reporters |
Two of these deserve a note. The login-screen XSS is the headline, but it is a targeted attack rather than a worm: reflected XSS only fires in the browser of whoever clicks the crafted link, so someone has to phish a specific administrator on your specific site. If that lands, though, an attacker can ride the admin session and install code — which is how “XSS” becomes “remote code execution.”
The other is the SSRF. On its own it looks minor. In practice it is the first step in moving from “your WordPress site” to “whatever else lives on your internal network,” which is why it matters more on self-managed infrastructure than on isolated shared hosting.
Four separate researchers independently found four Contributor-level stored XSS bugs in the same release cycle. That is worth reading as a signal: if you have handed out Contributor or Author accounts casually, this is the moment to audit that list.
Are you affected? A three-question check
- Are you running WordPress 7.0.4? If not, everything below is academic — update first. Dashboard → Updates shows your version, or find it at the bottom-right of any admin screen.
- Does your server use ImageMagick with Ghostscript? This is the precondition for CVE-2026-65640 specifically, and it is not a given. Many stacks use GD instead.
- Who holds an Author account or higher? Users → All Users, filtered by role. If that list is longer than the people you would trust with server access, shorten it.
For the second question, here is a snippet we ran on a production site before publishing this. Drop it in a temporary mu-plugin or run it through WP-CLI, read the result, then remove it:
// Reports whether this site meets the precondition for CVE-2026-65640.
if ( ! class_exists( 'Imagick' ) ) {
echo "Imagick not installed - not exposed to this flaw.";
} else {
$formats = ( new Imagick() )->queryFormats();
$gs = array_intersect( $formats, array( 'PS', 'EPS', 'PDF' ) );
echo $gs
? 'Ghostscript-backed formats enabled: ' . implode( ', ', $gs )
: 'Imagick present, no Ghostscript delegates - not exposed.';
}On the site we tested it against, Imagick was not loaded at all — WordPress was using the GD image editor, so the precondition was never met. That is a common outcome, and it is exactly why “check, don’t assume” beats panicking. It is also not an excuse to skip the update: 7.0.4 backports fixes across every supported branch, and the next flaw will not care which image library you chose.
How to update safely
- Take a backup you have actually restored before. An untested backup is a hope, not a plan.
- Check your current version. Dashboard → Updates, or
wp core versionvia WP-CLI. Do not assume automatic background updates ran — confirm. - Update core from Dashboard → Updates, or
wp core update. - Update plugins and themes in the same session. Core is a minority of real-world WordPress compromises; outdated plugins are the larger share.
- Audit user roles. Users → All Users. Remove dormant accounts, downgrade anyone who does not need Author or above, and require multi-factor authentication on what remains.
- Re-test the paths that make you money — checkout, contact forms, booking. A patched site that quietly broke its own lead capture is not a win.
The part worth more than the patch notes
Three WordPress security releases landed in roughly five weeks. Look at who found the bugs.
WordPress 7.0.2, the release before this run, closed a chain tracked as CVE-2026-60137 and CVE-2026-63030 — nicknamed wp2shell, an unauthenticated path from SQL injection to remote code execution. According to Patchstack’s write-up, that was not found by a researcher reading the batch API line by line. Searchlight Cyber pointed OpenAI’s GPT-5.6 Sol Ultra at WordPress core and had a working pre-auth SQL injection chained to RCE in about ten hours, at a compute cost of roughly twenty-five dollars.
Then look at 7.0.3 and 7.0.4. The login-screen XSS and the Imagick RCE are both credited to pwn.ai, a company built around autonomous penetration testing. The CSS injection filter bypass is credited to Anthropic directly.
Patchstack also published WordPress’s HackerOne intake, supplied by core security lead John Blackbourn: roughly nine years of monthly vulnerability reports in the dozens, then a sharp climb through spring 2026, reaching about 450 reports in July alone.
If a model can go from zero to working remote code execution in ten hours, the window between disclosure and exploitation is no longer measured in days.
None of this is bad news in itself. More eyes on open-source code, moving faster, is a long-term win for WordPress and for everyone downstream of it — these bugs were responsibly reported and fixed before disclosure, which is the system working exactly as designed. The nine-year-old Imagick flaw was found and closed rather than quietly exploited.
What has changed is the assumption underneath most maintenance schedules. “We’ll apply it at the next maintenance window” was a reasonable policy when finding an exploitable bug took a skilled human weeks. It is a policy built for a threat landscape that no longer exists. The same capability that lets a defender scan their own stack in an afternoon is available, at trivial cost, to whoever is looking for a way in.
What we would change about how you run WordPress
- Turn on automatic minor-core updates and then verify them. WordPress ships security releases to background updates by default. The failure mode is not the update — it is nobody checking that it landed. Put a monthly version check on someone’s actual calendar.
- Treat roles as a security boundary, not an org chart. Contributor and Author are not “junior” permissions. Four of the twelve issues in 7.0.3 and the entire 7.0.4 flaw sat behind exactly those roles.
- Disable XML-RPC unless something you own genuinely needs it. It is enabled by default, reachable without authentication, and was one of the two routes that bypassed WordPress’s own file-type check.
- Know what your stack actually runs. “Are we exposed?” should take minutes to answer, not days. If nobody can tell you which image library your server uses, that is the gap worth closing first.
- Shrink the window, not just the backlog. Virtual patching at the firewall layer buys time between disclosure and your update. It is not a substitute for updating.
WordPress 7.1 launches at WordCamp US, 16–19 August 2026, and the fixes above are already carried into its release candidates. If you have been putting off a version audit, this is a sensible week to do it.
Frequently asked questions
Do I need to update to WordPress 7.0.4 immediately?
Yes. WordPress classifies both 7.0.3 and 7.0.4 as security releases and recommends updating immediately. Even if your server does not meet the ImageMagick and Ghostscript precondition for CVE-2026-65640, 7.0.4 carries forward the twelve fixes from 7.0.3, several of which need no authentication at all.
What is CVE-2026-65640?
CVE-2026-65640 is an authenticated remote code execution vulnerability in WordPress core, fixed in version 7.0.4 on 12 August 2026. An attacker with an Author-level account or higher could upload a file with an image extension whose contents were actually PostScript. On servers where ImageMagick is wired to Ghostscript, that file was executed as a program instead of processed as an image.
Which WordPress versions are affected by CVE-2026-65640?
The flaw is present in WordPress core from version 4.7 through 7.0 — close to nine years of releases. WordPress has backported the fix through to the 4.7 branch and into the 7.1 release candidate, though only the most recent version of WordPress is actively supported.
Can an anonymous attacker exploit CVE-2026-65640?
No. It requires an existing account with Author-level permissions or higher, because the attacker needs the ability to upload media. There is no drive-by version. The risk scales with how many accounts you have issued and how well they are protected.
Is my site vulnerable if it does not use ImageMagick?
Not to this specific flaw. If WordPress is using the GD image editor rather than Imagick, or Imagick is installed without Ghostscript delegates, the precondition is not met. You can confirm this with the snippet earlier in this article. Update anyway — the release also carries the 7.0.3 fixes.
What was fixed in WordPress 7.0.3?
Twelve vulnerabilities, released 6 August 2026: one pre-authentication reflected XSS on the login screen (CVE-2026-64638), four Contributor-level stored XSS issues, a multisite privilege escalation, three information disclosure issues, an Author-level CSS injection, an email confirmation bypass, and a server-side request forgery flaw in URL validation.
Why are there so many WordPress security releases in 2026?
Vulnerability discovery has accelerated sharply because AI models are now capable of finding and chaining exploits independently. WordPress’s HackerOne intake ran at dozens of reports per month for roughly nine years, then climbed to around 450 reports in July 2026. Several 2026 core findings are credited to AI security firms. More bugs are being found and fixed, faster — which is good, provided you update at the same speed.
Sources
- WordPress 7.0.4 Release — WordPress.org, 12 August 2026. Official release note, CVE and GHSA references, backport scope.
- WordPress 7.0.3 Release — WordPress.org, 6 August 2026. The full twelve-item vulnerability list and credited reporters.
- WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed — Patchstack. Severity analysis, the wp2shell background, and the HackerOne report-volume data.
- WordPress 7.0.4 Fixes a PNG That Runs Code — webhosting.today, 13 August 2026. Technical breakdown of the Imagick and Ghostscript chain and the two bypass routes.
A note on severity scores: at the time of writing, the CVE records for these releases were not yet published at MITRE, and third-party CVSS figures in circulation vary. We have described severity in WordPress’s own terms and named the required access level for each issue instead of quoting a number we cannot verify.
If this is more than you want to own
Most businesses do not want a WordPress security practice. They want a site that stays up, stays fast and stays out of the news, without someone on staff tracking CVE numbers on a Tuesday night.
That is a maintenance posture, not a plugin: known versions, controlled access, verified backups, and someone whose job it is to notice. If you are not sure whether your site is patched — or you are fairly sure nobody has checked in a while — tell us what you are running and we will give you a straight answer. If you are weighing whether a platform still fits the business at all, our work on custom software and web development and on AI agents and automation is the longer conversation underneath this one.