• CodeRevolution
• Web Development

If you maintain a WordPress site that gives authors permission to upload media, this is an update to install now—not one to leave for the next maintenance window.

WordPress 7.0.4 was released on August 12, 2026 with a fix for an authenticated remote code execution vulnerability. The issue, tracked as CVE-2026-65640 and GHSA-8vr3-7mxf-gx8w, can be triggered by a malicious file upload from an Author-level user or any account with the equivalent upload_files capability when the server uses both Imagick and Ghostscript.

The public advisory rates the vulnerability High, with a CVSS score of 8.8 out of 10. A successful exploit can affect confidentiality, integrity and availability. In ordinary terms, it can turn permission to upload media into permission to run code on the server.

That does not mean every WordPress installation is equally exposed. The vulnerable path has specific prerequisites. It does mean every affected installation should receive its fixed Core release promptly, even when its current media configuration appears safe. Server packages change, hosting images are rebuilt, roles are customized and plugins can invoke image libraries in ways that are easy to miss.

WordPress 7.0.4 security update at a glance

The exploitation-status line deserves careful wording. The absence of a statement about active exploitation is not evidence that attempts are not happening. It simply means the primary sources do not currently establish that fact. With a high-severity RCE now publicly documented, waiting for telemetry would be a poor patch strategy.

What is CVE-2026-65640?

CVE-2026-65640 is a dangerous-file-upload vulnerability in WordPress Core’s image-processing boundary. According to the public advisory, a malicious user with the upload_files capability can upload crafted PostScript content on a site where Imagick and Ghostscript are in use. ImageMagick may delegate the interpretation of PostScript-family content to Ghostscript, and the advisory identifies Ghostscript’s handling of certain embedded files as the weakness that completes the route to code execution.

The high-level path looks like this:

authenticated upload → WordPress image editor → Imagick format handling → Ghostscript delegate → server-side code execution

This is not merely a browser-side script injection or a way to damage one media attachment. Remote code execution means attacker-controlled instructions can run with the operating-system permissions of the web or PHP process. Depending on the hosting configuration, that can expose wp-config.php, database credentials, salts, API keys and private content. It can also allow files or database records to be changed, new persistence mechanisms to be created, and the site to be taken offline.

The CVSS vector published with the advisory is CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H: the attack is network-reachable, has low complexity, requires low privileges and no action from another user, and can have a high impact across confidentiality, integrity and availability.

“Author+” is shorthand; upload_files is the real boundary

WordPress security advisories often describe access requirements by the lowest default role that can reach the vulnerable operation. In this case, “Author+” means Author, Editor, Administrator and Super Admin under the standard role configuration.

The decisive condition is not the role label. It is the upload_files capability.

WordPress gives Authors the upload_files capability by default, while Contributors and Subscribers do not receive it. Plugins can create custom roles or add capabilities to existing roles, however. A membership, front-end publishing, directory, marketplace or user-generated-content plugin may therefore create an exposed account type whose display name does not contain the word “Author.”

That distinction should shape the audit. Do not check only the Users screen for accounts with the Author role and declare the site safe. Check which accounts can actually upload files and which custom workflows accept uploads on their behalf.

An authenticated prerequisite also should not be treated as a small concern. Multi-author publications, client portals, education sites and contributor networks may have dozens or hundreds of eligible accounts. Old freelance accounts are forgotten. Passwords are reused. Session cookies are stolen. A compromised Author account is normally limited to content and media; CVE-2026-65640 can turn that foothold into server execution.

Why Imagick and Ghostscript matter

WordPress can edit images through different PHP-backed implementations. The GD library handles many common raster operations directly. Imagick is the PHP extension for ImageMagick and supports a broader set of formats and transformations.

Some of those formats are not decoded entirely inside ImageMagick. ImageMagick uses delegates—external programs that understand a particular document language or format. Ghostscript is commonly used to render PDF and PostScript content, which is why it often appears in the stack that generates preview images for uploaded PDFs.

That delegation creates a trust boundary. WordPress receives a file from a user. Imagick determines how it should be interpreted. If the content is treated as PostScript, ImageMagick may pass it to Ghostscript. The uploaded file has now reached an interpreter with a much larger execution surface than a JPEG decoder.

The advisory does not publish a universally safe Imagick or Ghostscript version threshold. It also does not say that updating Ghostscript alone is an equivalent remediation. The reliable WordPress-level fix is to install the patched Core release, which prevents content that might be PostScript from reaching Imagick through this path.

What WordPress 7.0.4 changes in Core

The WordPress 7.0.4 release notes identify wp-includes/class-wp-image-editor-imagick.php as the revised runtime file. The public Core commit is titled “Prevent loading images into Imagick which might be PostScript.” It adds 235 lines and removes 25.

The patch does more than block one extension. That would be too weak because image-processing libraries can infer a format from several signals, and attackers deliberately look for disagreement between them.

Before constructing or invoking Imagick, WordPress 7.0.4 now:

• derives a normalized “given filename” for local files and streams;
• identifies and removes ImageMagick-style format specifiers from the name while retaining them for validation;
• reads a resource header for content sniffing;
• requires files presented as PDFs to begin with the expected PDF signature;
• rejects PostScript-family content by format specifier, filename extension and known file signatures;
• rejects compressed wrappers that Imagick would otherwise decompress before deciding how to interpret the inner content;
• loads a stream once and passes the same validated bytes to Imagick, reducing the chance that validation examines different content from the content eventually processed; and
• routes PDF handling by a verified content signature instead of trusting the extension alone.

The important architectural change is straightforward: WordPress now makes the safety decision before handing the resource to a powerful, format-aware image stack. It checks multiple representations of the same input rather than trusting a filename, MIME claim or extension in isolation.

There is a compatibility consequence. The patch intentionally rejects compressed formats such as .svgz when they reach this Imagick path, and PostScript-family files will no longer be processed there. Standard raster images should be unaffected. PDF previews remain supported when the file has a valid PDF signature. Plugins that added uncommon media formats or sent remote streams into the Core image editor should test those workflows after updating—but a compatibility regression is not a reason to roll back a security fix.

Is your WordPress site vulnerable?

A site is in the documented vulnerable configuration when all three conditions are present:

1. It runs an affected WordPress Core release.
2. At least one potentially untrusted account has upload_files, or an attacker can compromise such an account.
3. The relevant media-processing path uses Imagick and Ghostscript.

The fastest check starts with the WordPress version. Look in Dashboard → Updates, or use WP-CLI:

wp core version
wp core check-update --minor --force-check

Then open Tools → Site Health → Info → Media Handling. WordPress normally reports its active image editor and ImageMagick details there. On a server where WP-CLI runs under the same PHP configuration as the website, this command provides another quick signal:

wp eval 'echo extension_loaded( "imagick" ) ? "Imagick loaded\n" : "Imagick not loaded\n";'

If you have shell access, you can also check whether a Ghostscript executable is visible:

command -v gs
gs --version

Treat negative results carefully. The command-line PHP binary can load a different set of extensions from PHP-FPM or Apache. Ghostscript can also be available to ImageMagick through a delegate configuration without being exposed as expected in your interactive shell. If Site Health and the shell disagree—or if you are on managed hosting—ask the host to confirm whether the web PHP process uses Imagick and whether ImageMagick can invoke Ghostscript.

Do not postpone the WordPress security update while resolving that question. Configuration discovery is useful for risk assessment and incident response; it is not a substitute for patching.

Fixed WordPress versions

WordPress backported the fix through the 4.7 branch. The 7.0.4 HelpHub page lists the following patched releases:

WordPress 4.6 and earlier do not receive this security backport.

Installing the branch-level patch is the quickest way to close this specific vulnerability without combining the emergency change with a major-version migration. It should not become an excuse to remain indefinitely on an obsolete branch. WordPress explicitly notes that only the most recent release line is actively supported; old-branch backports are a courtesy, not a complete long-term security policy.

How to update WordPress safely—and quickly

Take a current backup or storage snapshot if your recovery process requires one, but keep the response proportional. This is a small Core security release, and staging should not turn a same-day patch into a week-long project.

From the administration area, go to Dashboard → Updates, select the offered Core update and click Update Now. If you manage the site through WP-CLI, the official wp core update documentation supports a minor-branch update:

wp core check-update --minor --force-check
wp core update --minor
wp core version
wp core verify-checksums

The last command compares installed Core files with WordPress.org checksums. A successful checksum verification is useful evidence that the expected release files are present; it is not a full malware scan and says nothing about wp-content, the database or server-level persistence.

For a managed fleet, record the result per site. “The platform has automatic updates” is not verification. WordPress says sites that support automatic background updates will begin receiving the release, and minor and security updates are enabled by default on many installations, but updates can fail because of file permissions, version-control detection, disabled constants or filters, interrupted requests and hosting controls.

The desired evidence is an installed version at or above the fixed release for that branch—not an enabled checkbox.

What to test after the update

WordPress 7.0.4 changes media input validation, so the post-update check can stay focused. Confirm the installed version, run Core checksum verification, upload an ordinary JPEG or PNG, generate image sizes, and test a legitimate PDF upload if the site relies on PDF previews.

If a custom plugin accepts EPS, PostScript, compressed SVG or another uncommon format, test that feature separately. Rejection may be the intended new behavior. Review PHP and WordPress logs for invalid_image or “File is not an image” errors, then update the plugin’s workflow instead of weakening the new Core checks.

You do not need to purge a CDN to activate this patch. The vulnerable operation occurs in server-side media processing, not in cached front-end HTML. A normal cache purge may be part of your deployment procedure, but it is not what closes CVE-2026-65640.

What to do if you cannot update immediately

The permanent fix is the patched WordPress release. If an operational blocker makes that impossible for a short period, remove the documented prerequisites while the update is prepared.

Temporarily revoke upload_files from untrusted accounts and pause front-end upload workflows that ultimately process files through WordPress’s Imagick editor. Ask the hosting provider to disable the relevant ImageMagick/Ghostscript delegate path or force WordPress media handling away from Imagick if they can do so safely. Restrictive ImageMagick security policies can reduce exposure, but policy locations and delegate behavior vary considerably between hosts.

These are containment measures, not alternate patches. Plugins may instantiate the Imagick class directly, bypassing WordPress’s editor selection, and removing upload access can disrupt editorial or customer workflows. A web application firewall is also unlikely to be a dependable substitute because the dangerous content travels through an authenticated, legitimate upload feature.

Document every temporary change so it can be reviewed after Core is secure. Most importantly, make the delay hours rather than days.

Should you investigate for compromise?

The primary sources did not report observed exploitation when this article was checked. Still, a site that had untrusted Author-level accounts, suspicious logins or unexpected uploads while running an affected version deserves additional review.

Start with the accounts and capabilities that could reach the vulnerable path. Look for dormant authors, recently changed email addresses, password resets and unexpected sessions. Review recent Media Library entries and files under wp-content/uploads, especially content whose real type does not match its extension. Check for new administrators, unfamiliar must-use plugins, modified PHP files, unexpected scheduled tasks and changes to wp-config.php.

These read-only WP-CLI and shell checks can support triage:

wp user list --fields=ID,user_login,user_email,roles,user_registered
wp core verify-checksums
wp cron event list
find wp-content/uploads -type f -iname '*.php' -print

An empty result does not prove the site is clean. Conversely, an unexpected file is not automatically malicious. Preserve logs and file timestamps before making broad changes. If there are credible indicators of code execution, isolate the site, capture evidence, rotate WordPress and infrastructure credentials, replace application code from known-good sources, inspect the database and restore from a verified clean backup where appropriate. Reinstalling Core alone is insufficient if an attacker established persistence elsewhere.

What plugin and platform developers should review

The Core patch protects media processed through WP_Image_Editor_Imagick. A plugin that creates new Imagick() directly owns its own input-validation boundary and does not inherit every protection WordPress added in 7.0.4.

Search custom code for direct Imagick construction, remote streams passed to image editors, PDF preview generators, SVG or archive expansion, and upload endpoints that grant temporary capabilities. Verify that authorization is checked on the server and that files are allowlisted by their intended business purpose. An extension and a client-supplied MIME header are not sufficient evidence of content type.

The patch also illustrates a broader secure-processing pattern: normalize the name, inspect the bytes, reject interpreter-capable formats, avoid transparent decompression of untrusted content, and ensure that the bytes validated are the exact bytes later processed. When a library can delegate to an external interpreter, treat that transition as a security boundary rather than a harmless implementation detail.

Agencies should add this case to their WordPress maintenance runbooks. Inventory custom roles by capability, record which media stack each host supplies, track Core versions centrally and preserve a fast minor-release deployment path. WPBay’s Security & Patching Guidelines for 2026 provides a wider framework for handling urgent releases without improvising on production.

Frequently asked questions

Is WordPress 7.0.4 a critical security release?

The public GitHub advisory rates CVE-2026-65640 High, not Critical, with a CVSS score of 8.8. The remote-code-execution impact still makes it an immediate update, particularly on multi-author sites and platforms with user uploads.

Is every WordPress site vulnerable to CVE-2026-65640?

No. The documented exploit requires an affected WordPress version, a user with upload_files, and a server path using both Imagick and Ghostscript. Updating remains the right action because role capabilities and server media stacks are often customized or changed without a site owner noticing.

Are Contributors and Subscribers able to exploit it?

Not under WordPress’s default roles because neither role has upload_files. A plugin or administrator can add that capability, so custom roles must be checked by capability rather than name.

Will WordPress 7.0.4 install automatically?

Many sites support automatic background updates for minor and security releases, and WordPress says the rollout has begun. Verify the installed version in Dashboard → Updates or with wp core version; do not assume the job completed successfully.

Can I update Ghostscript instead of WordPress?

No primary source for CVE-2026-65640 identifies a Ghostscript version that should replace the WordPress fix. WordPress 7.0.4 hardens the application boundary so PostScript-like content is rejected before it reaches Imagick. Install the Core update even if the operating-system packages are current.

Does switching from Imagick to GD fix the issue?

It can remove the documented Core processing path as a temporary containment measure, but it is not equivalent to patching. Plugins can call Imagick directly, the active editor can change, and some media features behave differently under GD.

Do older WordPress sites have to upgrade directly to 7.0.4?

Not to close this specific issue. Fixed releases are available for branches from 4.7 through 7.0. Install the fixed release for the current branch immediately, then plan a tested move to the current supported WordPress line.

Does a security plugin or WAF block this vulnerability?

It may add detection or reduce exposure, but it should not be treated as the fix. The documented route uses a legitimate authenticated upload operation and a server-side image-processing chain. Updating Core closes the vulnerable boundary directly.

The practical conclusion

WordPress 7.0.4 is a focused security release for a high-impact flaw. It blocks malicious PostScript content from crossing the WordPress-to-Imagick boundary where Ghostscript could process it, and it does so with layered checks rather than a fragile extension blacklist.

Update WordPress 7.0.0–7.0.3 to 7.0.4 now. If a site remains on an older branch, install the listed backport and then schedule the larger supported-version upgrade. Confirm the version, verify Core checksums, test the media workflows that matter and review capable accounts if the site accepts uploads from people outside the trusted administration team.

The vulnerability has prerequisites. The patch does not.

Primary sources

• WordPress 7.0.4 release announcement
• WordPress 7.0.4 HelpHub release notes and backports
• CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w advisory
• WordPress Core security commit for the Imagick editor
• WordPress roles and capabilities documentation
• Official WordPress update documentation
• Official WP-CLI Core update documentation