WordPress 7.0.4 shipped on 12 August 2026, six days after 7.0.3. Two security releases inside a week is the sort of thing that gets noticed, and not kindly. If you manage a WordPress website, you’ve probably had someone forward you a headline and ask whether the platform’s falling apart.
It isn’t. But the reason it isn’t is more interesting than the usual reassurance, and it changes what’s actually worth worrying about.
Disclaimer: nobody at WordPress is holding us at gunpoint. We build WordPress sites for a living, so we’re biased in the boring, voluntary way. Mostly we’re just tired of headlines that treat every security release as a scandal, when a patched bug is the system doing its job.
What 7.0.4 actually fixes
One vulnerability. CVE-2026-65640, rated High at CVSS 8.8: authenticated remote code execution via a malicious file upload.
The mechanism matters, because it decides whether you care. When WordPress uses ImageMagick to process an uploaded image, ImageMagick hands PostScript and PDF files to Ghostscript. The weakness sits in Ghostscript’s handling of certain embedded files. WordPress core isn’t where the bug lives; core is what passes the file along, because the old code decided how to treat an upload by trusting its file extension. The patch rebuilds that decision around what the file actually contains.
Two conditions both have to be true before this touches you:
- Your server runs Imagick and Ghostscript together. Plenty of stacks use the GD library instead, and plenty running Imagick don’t have Ghostscript at all.
- An attacker holds an account with the
upload_filescapability, which on a default install means Author, Editor or Administrator. Contributors can’t upload files, so Contributor access isn’t enough.
If either is false, this particular issue doesn’t reach you. You can check the first in your dashboard under Tools, then Site Health, then the Info tab, where the Media Handling section reports both versions directly.
The exposure profile is narrower than 7.0.3’s, but sharper where it lands. It needs an account, but no user interaction at all: nobody has to be tricked into clicking anything. If several people hold Author accounts on your site, say a member-contributed blog, a campaign site with freelance writers, or a multi-charity portal, this is the one to move on first.
The fix has been backported to every branch WordPress still supports, all the way back to 4.7. You don’t need a major version upgrade to be patched.
Who found it
Now the main purpose of this article.
Both the official release announcement and the GitHub advisory credit the same reporter, and the advisory’s wording is worth reading twice:
“Discovered and responsibly disclosed by the team at pwn.ai.”
WordPress security advisory, GHSA-8vr3-7mxf-gx8w
pwn.ai is an autonomous penetration testing platform built by Octagon Networks, an offensive security firm with more than fifty published CVEs. Their product is an agentic AI swarm that crawls a target, maps the attack surface, chains bugs together and writes working exploits. As they describe it themselves, “pwn.ai is our methodology, automated”. Their bar for reporting: if the engine can’t exploit it, it doesn’t get reported.
And this wasn’t a one-off. Six days earlier, pwn.ai also reported the headline vulnerability in WordPress 7.0.3: CVE-2026-64638, the pre-authentication cross-site scripting issue on the login screen. Two consecutive core security releases, and the most serious issue in each came from the same AI-driven outfit.
Look further down the 7.0.3 credits and the pattern holds. Alongside a dozen named human researchers sit Aikido Security, an automated code security company, and Anthropic, an AI lab. A quarter of the reported issues in that release came from organisations whose method is machine-driven analysis rather than a person reading source code at midnight.
The bug is older than the tools that found it
The advisory lists the affected versions, and the vulnerable code path exists in every branch back to 4.7, which shipped in December 2016. Whatever else this bug is, it isn’t the product of sloppy recent work. It sat in production, on a meaningful share of the web, for the best part of a decade.
Thousands of developers have read that code. It’s been through years of review. It survived every scanner and every bug bounty hunter pointed at WordPress since 2016. Then a machine read it and found the problem.
That’s the honest reading of the current run of security releases. The code didn’t get worse. The reading got better.
The wider numbers back this up. Patchstack’s State of WordPress Security in 2026 report recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42% jump on the year before. Of those, 91% were in plugins and 9% in themes.
11,334 vulnerabilities were found across the WordPress ecosystem in 2025. Six were in WordPress core, and all six were low priority.
Patchstack, State of WordPress Security in 2026
Core isn’t where your risk lives, and it hasn’t been for years.
The part that cuts the other way
If the argument stopped there it’d be comfortable and half true. So here’s the other half.
The same capability that found this bug before an attacker did is available to attackers, and Patchstack says so directly: bad actors are already using AI to find and exploit vulnerabilities, while security teams wade through a flood of AI-generated reports of wildly varying quality. Elsewhere, autonomous agents like XBOW have topped HackerOne’s global leaderboard with more than a thousand validated findings, and Google’s Big Sleep agent found a SQLite flaw that was already known to threat actors before it was patched.
So the tempting conclusion, that patches now arrive faster than exploits, isn’t what the evidence shows. It shows the opposite.
Estimated mean time-to-exploit in 2025: minus seven days. On average, exploitation now begins before a patch exists.
Mandiant, M-Trends 2026
Mandiant’s M-Trends 2026 puts that figure on the whole software landscape, and Patchstack’s data tells the same story from the WordPress side: a weighted median of five hours from disclosure to first exploitation for heavily targeted vulnerabilities, 45% exploited within twenty-four hours, and 46% of 2025’s vulnerabilities disclosed with no fix available on day one.
Both things are true at once. Discovery has accelerated, which is why you’re seeing more releases. Exploitation has accelerated too, and by most measures rather more.
Which means the release itself was never the risky part. WordPress took a responsible disclosure, patched it, and backported the fix across twenty-four branches on the same day. That’s a healthy process working as designed. The risk sits entirely in the gap between the patch shipping and it reaching your site.
What this means if you run a WordPress website
Three things follow, and none of them is “worry about WordPress”.
Judge the platform by core, not by the ecosystem
Six low-priority core vulnerabilities in a year, against 11,334 across the wider ecosystem, tells you where to spend your attention. Your plugin list is your real risk register. Every plugin you install is a standing bet on someone else’s code quality and someone else’s disclosure process. Audit the list, and delete rather than deactivate: deactivated plugin code still sits on your server.
Treat update latency as the metric that matters
Not update count. If your sites run automatic background updates, 7.0.4 almost certainly landed without anyone lifting a finger, which is exactly what minor releases are designed for. The sites that get hurt are the ones where auto-updates were switched off during a debugging session two years ago and never switched back on, or the forgotten staging copy that’s still publicly reachable and carries the same exposure as the live site. If you’re not sure what your sites are running, our free WordPress version checker will tell you in seconds.
Look at who holds Author access
For this specific vulnerability, that’s the control that counts. Charities accumulate accounts: the campaigns officer who left in 2023, the agency that rebuilt the site before last, the volunteer who wrote three blog posts in 2019. Least privilege is unglamorous, and it’s also the cheapest fix on this list.
Quick answers
Is WordPress 7.0.4 urgent?
It depends on your site. If your server runs Imagick with Ghostscript and people you don’t fully trust hold Author accounts or above, update today. If either isn’t true, update promptly on your usual schedule. WordPress hasn’t published any evidence of exploitation in the wild at the time of writing.
Will my site update itself?
Sites that support automatic background updates pick up minor security releases on their own, usually within hours. Worth confirming rather than assuming, especially anywhere a plugin or a wp-config constant has disabled auto-updates.
Is WordPress still a safe choice for websites?
Yes, and the evidence is stronger than the headlines suggest. Six core vulnerabilities in a year, all low priority, and a security team that patches and backports across a decade of branches in a day. The risk conversation belongs with your plugins, your user accounts and your update process, not the platform.
The uncomfortable good news
A drumbeat of security releases reads like decline. On the evidence it’s closer to the opposite: a decade-old flaw in widely deployed code, found by a friendly machine rather than a hostile one, disclosed responsibly, patched, and backported to branches from 2016 on the same day.
The thing worth being uneasy about isn’t that WordPress shipped two security releases in a week. It’s that the same machines are now reading everyone’s code, including the plugins whose authors never set up a disclosure process, and that the median gap between a vulnerability going public and bots probing for it is about five hours.
Which is a question about your update process, not your CMS. If nobody at your organisation owns that process, that’s exactly what our WordPress support and maintenance plans exist for.
Sources
- WordPress 7.0.4 Release, WordPress.org, 12 August 2026
- WordPress 7.0.3 Release, WordPress.org, 6 August 2026
- Security advisory GHSA-8vr3-7mxf-gx8w / CVE-2026-65640, WordPress on GitHub
- The 7.0.3 to 7.0.4 code changes, WordPress on GitHub
- pwn.ai, Octagon Networks
- State of WordPress Security in 2026, Patchstack in partnership with Monarx
- M-Trends 2026, Mandiant / Google Cloud
