In the space of a week, WordPress shipped two security point releases: 7.0.3 on 6 August 2026 and 7.0.4 on 12 August 2026. The second is the one to read about. It fixed a vulnerability that let an author-level account, not an administrator, run code on the server.
7.0.3: "several security fixes"
WordPress 7.0.3 shipped on 6 August 2026 and its release note describes "several security fixes" without naming them, which is normal for this kind of release. Six days later 7.0.4 followed with one named vulnerability and a clear disclosure.
7.0.4: remote code execution from an Author account
7.0.4 patched CVE-2026-65640 (GHSA-8vr3-7mxf-gx8w): an authenticated user with Author-level access or higher could achieve remote code execution through a malicious file upload, on sites using the Imagick PHP extension together with Ghostscript. Author is a role many agencies hand to clients or contributors who only need to write and publish posts, which is what makes this one worth reading past the headline.
Patched everywhere WordPress still supports
The issue was reported through WordPress's HackerOne program by the pwn.ai team. Because it is a security fix it was backported across every supported branch: 6.9 received 6.9.7, 6.8 received 6.8.8, and the fix reaches back to 4.7.35. It was also folded into the 7.1 release candidate a week later, so a site that updated straight to 7.1 "Mary Lou" got the fix in that update.
| Branch | Patched in |
|---|---|
| 7.0 | 7.0.4 (or 7.1) |
| 6.9 | 6.9.7 |
| 6.8 | 6.8.8 |
| Older branches | Backported down to 4.7.35; see the release note for the full list |
Why the backport matters more than the version number
A lot of security advice assumes everyone runs the newest major version. In practice, sites sit on 6.x branches for years because of an old theme or a plugin that was never tested against a newer core. Those sites were exactly who the backport was written for. "Current for its branch" is the standard to check against, not "current, full stop".
What to check on your own sites
- Every site at least on the patched release for its branch: 7.0.4 or later, 6.9.7 or later, 6.8.8 or later, and so on down the published list.
- If you cannot confirm whether Imagick and Ghostscript are in use on a given host, patch anyway rather than trying to rule the exposure out.
- Which accounts hold Author access or higher on each site. Author looks like a low-risk role from a publishing standpoint and is not one from a security standpoint.
Patch speed matters more when an attacker only needs a foothold to escalate from, which is the theme running through the ClickFix campaign as well: an exposed or over-permissioned account is often the whole story.
How to see the WordPress version on forty sites without logging into forty sites
Any dashboard that manages your sites should show core, PHP and plugin versions per site in one list. If yours does not, the quick check from outside is the generator meta tag in the page source or the readme.html file that WordPress ships with, though a well-configured site hides both. From inside, the Updates screen in wp-admin shows the current version and whether a minor release is waiting. Whatever the method, the answer per site should be "on the patched release for its branch", and the list should be something you can produce in a minute when the next advisory lands.
Who has Author access, and why
This vulnerability turned a publishing role into a server-level problem. That is a good reason to look at the user list with a different eye. An Author can upload files and publish posts. On many client sites that role is given to a marketing contact, a former intern, or a contractor who wrote three articles in 2024 and never came back. Every one of those accounts is a way in if its password was ever reused. Remove the ones that are not in use; downgrade the ones that only need to draft to Contributor, which cannot upload files.
What automatic minor updates do and do not cover
WordPress installs minor releases like 7.0.4 on its own unless that has been switched off, and it should stay on. Two limits are worth knowing. First, it only updates within the branch the site is on: a site on 6.8 gets 6.8.8, not 7.0.4, which is exactly why the backports exist. Second, some hosts and some management plugins disable automatic updates so that they can control them centrally; then the update only happens when that tool runs. Check which situation each site is in, and make sure "somebody else handles it" is a name and not an assumption.
Sources
- WordPress.org, "WordPress 7.0.4 Release"wordpress.org/news, published 12 August 2026
- WordPress.org release index, date and description of the 7.0.3 releasewordpress.org/news/category/releases