Last month we wrote about the WordPress flaw that let attackers in without a password. That was the 7.0.0 and 7.0.1 mess. wp2shell. An unauthenticated REST API hole, followed by bots scanning for freshly updated sites.
This time the flaw is different. WordPress 7.0.4 arrived on August 12, and we pushed it to every site we maintain yesterday. Not because one of them had already been hit. The whole point of a security update is to get there before the cleanup jobs start.
If you take one thing from this article, make it this: update WordPress now. Keep reading if you want to know why 7.0.3, 7.0.4, and July’s no-password flaw are three separate things.
Two serious security releases in six days
WordPress 7.0.3 landed on August 6. It fixed CVE-2026-64638, a vulnerability that researchers at pwn.ai called XSS2Shell. The starting point was reflected XSS on wp-login.php. An attacker did not need an account to trigger the XSS, but turning it into PHP code execution required a logged-in administrator to open a specially crafted link.
That distinction matters. It was not another bot-only break-in like July. It needed the right victim, already signed in, to visit the wrong URL. If that happened, the chain could use the administrator’s session to create an Application Password, install a malicious plugin, and reach code execution on the server.
Then came WordPress 7.0.4, only six days later. CVE-2026-65640 is a completely separate flaw. A user with the Author role or higher can upload a malicious PostScript file. On a server running both Imagick and Ghostscript, processing that file can lead to remote code execution.
In plain English: WordPress accepts the upload, Imagick handles the image processing, and Ghostscript gets involved with the PostScript file. The dangerous part sits in that chain. If exploitation succeeds, the attacker is no longer limited to editing a blog post. They can run code as the web server user.
Is your server actually exposed?
If your host uses GD and does not have Imagick with Ghostscript, this specific attack does not work. Plenty of cheaper shared hosting plans fall into that group. Imagick and Ghostscript are common enough on VPS servers and higher-end hosting, though, that guessing is a poor security plan.
Most business owners have no idea which image library their server uses. That’s normal. WordPress does not give you a neat switch labelled “Imagick and Ghostscript enabled.” You can ask your host or inspect the PHP environment, but don’t hold the update while you wait for an answer. Patch first. Investigate later if you’re curious.
WordPress also announced backports for older branches down to 4.7. If your site still runs 6.8 or 6.9, check for the security release made for that branch. Use it. Don’t make an unplanned jump to WordPress 7.0 on a Friday night if a major-version update still needs compatibility testing.
Why this isn’t July all over again
The July flaw required no account at all. That’s why it spread so quickly. We cleaned an Estonian cosmetics WooCommerce shop the next morning, a manufacturing company site that same day, and another Estonian shop where the infection had already been sitting for 12 days. A Latvian heating company was caught in the same wave. Every case traced back to wp2shell and the 7.0.0 or 7.0.1 vulnerability.
The flaw fixed in 7.0.4 requires at least an Author-level account. That narrows the field, but it doesn’t make the bug harmless. Guest writers have Author accounts. Shop staff upload product photos. An intern may have “posts only, no admin” access and still be allowed to upload files.
This is a good reason to review roles. If someone only needs to write drafts, Contributor may be enough. Keep upload permissions for people who genuinely need them. But don’t confuse tidier permissions with a patch. Update first, then clean up the user list.
None of the sites on our maintenance list were hit through this flaw. We didn’t wait around for the first case.
What we actually did yesterday
We rolled 7.0.4 across the maintenance fleet. Run the update. Confirm the site came back. Check the version number. Move to the next one. That’s the boring side of WordPress maintenance, and I much prefer it to sending a cleanup invoice.
If your site has behaved strangely since July and nobody properly cleaned it, updating core is still only step one. Malware left inside wp-content/uploads does not care that the dashboard now says 7.0.4. At that point you need a proper hacked WordPress cleanup: files, users, database, backdoors, and the original entry point.
The first steps are the same ones covered in what to do the moment you suspect a compromise. Don’t start deleting random files. Take a snapshot, map the damage, and clean from evidence.
An unexpected PostScript file in the Media Library is also the sort of change file integrity monitoring can help surface, depending on which directories are watched. It won’t undo an attack. It can tell you that a file appeared where it shouldn’t.
One correction about XSS2Shell and 2FA
Two-factor authentication is still useful. Turn it on. It protects accounts when passwords are stolen and blocks a huge amount of ordinary account takeover. Our 2FA guide explains the practical setup.
But 2FA does not patch XSS2Shell, and it does not rescue a session that is already authenticated. The 7.0.3 attack specifically relied on an administrator already being logged in. The fix is the WordPress security update. No plugin setting should be presented as a substitute.
Do these three things today
- Open Dashboard → Updates and install WordPress 7.0.4, or the security release for your current branch.
- Check the version number after the update. Don’t assume the automatic updater completed successfully.
- Review every user who can upload files. If they don’t need that permission, reduce the role.
Automatic updates save a lot of sites, but they can fail because of file permissions, a stuck maintenance state, or hosting restrictions. Look at the version yourself. If it doesn’t show 7.0.4 or the correct patched release for your branch, the job isn’t done.
July was the no-password flaw. August 6 fixed the login-page XSS. August 12 fixed the Author-level PostScript route on servers with Imagick and Ghostscript. We updated every maintenance site yesterday. Check yours today.