WordPress 7.0.4 arrived on 12 August 2026, six days after 7.0.3. It fixed a single vulnerability, rated High, and it was remote code execution. Most coverage said update immediately and stopped there.
Update immediately is correct advice. It is also the least interesting part, because it tells you nothing about your actual exposure, and exposure is what determines whether this is a two in the morning problem or a Tuesday morning one.
Two things had to be true
The issue, tracked as CVE-2026-65640, required an attacker with an account holding the upload_files capability. In a default WordPress install that means Author, Editor or Administrator. Contributors cannot upload files, so contributor level access was not enough. It also required the server to be running Imagick with Ghostscript.
If either condition is false on your site, that specific vulnerability did not reach you. That is not a reason to skip the update. It is a reason not to panic about it, and more usefully, it is a reason to go and look at who actually has upload rights on your site.
The user roles audit almost nobody runs
This is the real lesson buried in the release. Most small business WordPress sites accumulate accounts. The developer who built it in 2022. The intern who wrote three blog posts. The agency that ran a campaign. The plugin that created a service account. Each of those is an Author or Administrator, and each of them is a route into a vulnerability class that requires exactly that.
Open Users in your dashboard and read the list honestly. For each account, ask whether that person still needs access, and whether they need the role they have. A copywriter who publishes posts does not need Administrator. A client who reviews drafts does not need Author.
- Remove accounts for people who have left. Reassign their content rather than deleting it.
- Downgrade anyone who does not need to install plugins or edit users.
- Enforce two factor authentication on every remaining Administrator.
- Check for accounts you do not recognise. That one is not paranoia, it is the first sign of a prior compromise.
Why the backport story matters
The fix was backported through to the 4.7 branch. That is unusual and it is deliberate: a security only release lands across every supported branch on the same day, so a site running an older major version gets patched without being forced through a major upgrade it is not ready for.
This is genuinely useful if you are managing an old client site that cannot jump to 7.x this week. It is not a licence to stay there. Plugin and theme vulnerabilities are tracked and patched separately, which is why keeping core current is necessary but never sufficient.
Automatic updates and the case for turning them on
WordPress enables automatic background updates for minor and security releases by default. A surprising number of sites have this disabled, usually because a host or an optimisation plugin turned it off years ago and nobody noticed.
A quarterly plugin review belongs in the same routine, using the process in how to vet a WordPress plugin. Check it. In most cases minor security updates should be automatic, because the window between a public advisory and active exploitation is now measured in hours rather than days. Major version updates are a different decision and should stay manual, tested on staging first.
The advisory itself is indexed in the GitHub Advisory Database. You can read the full release details in the official WordPress 7.0.4 release announcement.
What we do on managed sites
On the sites we maintain, minor and security releases apply automatically within hours of publication. Major releases go to a staging copy first, get tested against the plugins that actually matter for that site, and go live once. Backups run before every major update and are restored to staging quarterly to prove they work.
None of that is clever. It is just the difference between hearing about a CVE and having already handled it. If you want the full routine, our WordPress maintenance checklist lists everything we run.
Frequently asked questions
Do I need to update if I have no Author accounts?
Yes. Your exposure to this specific issue may be nil, but security releases frequently bundle hardening changes, and the account situation on a site changes the moment someone new is added. Updating a minor release is low risk and takes seconds.
How do I check if my server uses Imagick and Ghostscript?
Go to Tools then Site Health then Info, and open the Media Handling section. It lists the image processing library in use. If it names ImageMagick, ask your host whether Ghostscript is enabled. Many managed hosts disable Ghostscript specifically because of this class of issue.
Should WordPress auto updates be turned on?
For minor and security releases, yes, on almost every site. The gap between an advisory being published and bots scanning for it is now very short. Major version updates are a separate setting and should stay manual so you can test on staging first.
Is core updating enough to keep a WordPress site secure?
No. Core is usually not where breaches originate. Outdated plugins and themes, weak or reused passwords, missing two factor authentication, too many administrator accounts and untested backups cause far more real incidents than core flaws do.
What if I am running WordPress 5.x or 6.x?
You received the backported fix on the same day, provided your site actually applied it. Check Dashboard then Updates to confirm your version number matches the latest release on your branch. Sites older than 4.7 receive no security updates at all and need to move to a supported branch.