← All articles

News

WordPress 7.0.4's RCE Patch: What Snippet Authors Should Audit This Week

CVE-2026-65640 is an Author+ RCE via Imagick and Ghostscript, backported to 4.7. Core is patched. Your upload-handling snippets and 'helpful' file PHP may not be.

August 13, 2026 4 min read Mark Ashton

  • wordpress
  • security
  • news
  • php
Abstract cover artwork for WordPress 7.0.4's RCE Patch: What Snippet Authors Should Audit This Week

WordPress 7.0.4 shipped on 12 August 2026 as a security release. John Blackbourn's post on WordPress.org is short on purpose: update now. The fix is CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w, reported by pwn.ai. CVSS 8.8. Authenticated Author or higher. Remote code execution on sites that use Imagick and Ghostscript, via a malicious upload that looks like an image.

Patchstack's write-up is the clearest technical summary: WordPress trusted the file extension; ImageMagick inspected the bytes, found PostScript, and handed the file to Ghostscript. A PNG that is secretly a PostScript program is enough. Some upload paths skipped the content checks core already had. 7.0.4 changes load() so content is checked before Imagick, and filenames cannot steer Imagick into Ghostscript.

The backport list is the other headline. The fix is going out through the 4.7 branch — December 2016. A bug that old, in a path that common, is why "we are on a recent minor" is not a personality trait. It is a patch Tuesday.

Update core. Then do not stop.

If you only do one thing, install 7.0.4 (or the backport for your branch). Sites with automatic background updates should already be moving. 7.1 RC3 was due the same day; do not skip 7.0.4 because a major is "almost out."

August 2026 also shipped 7.0.3 with a cluster of fixes, including login-screen XSS that needed no account. The Help Webmasters note from this month is blunt: updating is necessary and no longer sufficient. A patched core does not inventory the PHP *you* added.

That is the snippet-shaped remainder of this incident.

What to grep in your snippet library

You are looking for custom code that reimplements or shortcuts uploads:

  • wp_handle_upload, wp_import_handle_upload, media_handle_sideload
  • Direct move_uploaded_file or $_FILES handling
  • Passing user-controlled paths into Imagick, WP_Image_Editor, or shell_exec / convert
  • "Allow SVG / EPS / PDF preview" snippets that relax upload_mimes and then render the file
  • Anything that trusts $_FILES['x']['type'] or the extension alone

Author-level RCE is the nightmare case for snippet plugins because Authors are supposed to upload images. A snippet that "helps" Authors by widening mime types or by sending every upload through Imagick is now in the same story as core was. If you added that snippet in 2019 and it still runs, it did not get a 7.0.4 backport. You are the maintainer.

Ghostscript and Imagick are environment, not WordPress

CVE-2026-65640 needs Imagick + Ghostscript on the host. Many hosts enable both so PDFs and CMYK uploads generate thumbnails. Shared hosting you do not control may still have Ghostscript. "We do not think we use it" is not an audit.

If you can, ask the host whether Ghostscript is invoked for uploads. If you cannot, assume yes on any host that offers "PDF thumbnails" or "advanced image processing."

Playground and a local PHP built without Imagick will not reproduce this bug. That is a limitation we already flagged in the Playground testing guide. Environment-specific RCEs need staging that matches production extensions.

Snippet plugins as a second upload surface

A snippet manager that lets non-Administrators paste PHP is a worse bug than a loose mime type. Treat the snippet UI as unfiltered_html plus edit_plugins. If an Author can open it, you handed them RCE before this CVE existed. Restrict the capability. That is item two in is it safe to store custom code.

File-based + HMAC does not stop a privileged user from saving a malicious snippet. It tells you if the file changed after they saved it. Different threat. Both matter.

A one-hour audit

  • Confirm WordPress is 7.0.4+ (or the matching backport)
  • Search snippets and mu-plugins for the symbols above
  • Deactivate "allow extra image types" snippets until you have read them
  • Run a security audit on anything that touches files, images, or $_FILES
  • Check that snippet admin is Administrator-only
  • Verify backups restore; 7.0.3 + 7.0.4 in the same month is a reminder that patch velocity is up

If you use the Snippet Engineer to generate upload helpers, do not skip the audit gate. Generated code loves $_FILES['tmp_name'] and a comment that says "validate the type."

Supply chain, briefly

The same August window included a reminder that a fully patched site can still lose if a plugin loads a remote banner or a poisoned feed. That is not CVE-2026-65640, but it is the same operational lesson: inventory what your stack executes. Snippets that file_get_contents a remote PHP "license check" or eval a JSON body are in that set. Delete them.

After you patch

Write down which snippets touch uploads. Put them in a folder or tag you re-open on every core security release. Core can backport to 4.7. Your gist from 2018 cannot.

We will keep the WordPress 7.0 / PHP 8.4 checklist for platform upgrades. This post is the security-release twin: when WordPress fixes a loader, go looking for the loaders you wrote yourself.

Next

Ready to upgrade your snippet workflow?

GitHub sync, the Snippet Engineer, and security auditing — in one WordPress plugin.