WordPress 7.0.4 Fixes Critical Imagick RCE: How a Malicious PNG Could Become Server-Side Code Execution

WordPress 7.0.4 is a security release that addresses a remote code execution vulnerability in the way WordPress processes uploaded media through the Imagick image editor and Ghostscript. The vulnerability, tracked as CVE-2026-65640 and referenced as GHSA-8vr3-7mxf-gx8w, was reported by researchers at pwn.ai.

The important detail is the required privilege level. This is not an unauthenticated attack against an ordinary WordPress installation. An attacker needs an authenticated account with Author-level privileges or higher. That matters, but it does not make the vulnerability insignificant. On sites where authors, contributors, clients, members, or other semi-trusted users can upload media, a malicious file could cross the boundary from the WordPress media subsystem into server-side code execution.

The vulnerable path is particularly interesting because the uploaded file does not necessarily have to look dangerous to WordPress. A file can be given an image-looking name such as holiday.png while containing data that ImageMagick interprets as PostScript. Once that content reaches the ImageMagick/Ghostscript processing chain, the extension is no longer a reliable indicator of what is actually being parsed.

WordPress has historically supported a wide range of media processing through ImageMagick. That support is useful for generating thumbnails and previews, but it also means that a file upload can potentially reach parsers for formats that administrators do not normally associate with an image upload. WordPress itself has documented the ImageMagick-to-Ghostscript relationship for PDF rendering, including the fact that Ghostscript is a separate component used by ImageMagick for PostScript/PDF processing. (WordPress Trac)

The vulnerability in plain terms

The underlying problem is a mismatch between what WordPress thinks a file is and what ImageMagick ultimately interprets the file as.

A normal WordPress image upload appears straightforward. A user uploads something such as:

photo.png

WordPress validates the upload, stores it in the media system, and eventually passes it to an image editor to generate resized versions and other derivatives.

The security problem arises when the file’s name and its actual contents disagree.

A malicious file can be constructed so that its filename suggests an ordinary PNG while its contents contain PostScript data. WordPress’s upload validation normally has mechanisms for detecting mismatches between extensions, MIME types, and file signatures. The problem identified in CVE-2026-65640 is that not every path by which bytes can enter WordPress’s media-processing pipeline performed the same validation before the file reached the Imagick backend.

That creates a dangerous sequence:

authenticated upload → insufficient content validation → Imagick parses actual file contents → PostScript/EPS handling → Ghostscript → attacker-controlled code execution

The significance of the bug therefore isn’t that WordPress simply allowed an .png upload. The important issue is what happened after that file was accepted.

Why ImageMagick changes the security boundary

ImageMagick is considerably more than a PNG/JPEG resizing library.

It is a general-purpose image processing framework capable of reading and converting a large number of formats. Depending on the installed delegates and configuration, ImageMagick can invoke other software to process formats it does not handle entirely by itself.

One of those components is Ghostscript.

Ghostscript is primarily a PostScript and PDF interpreter. It is commonly used in Linux and Unix environments to render or convert PostScript-family documents. WordPress’s support for PDF previews is one reason this relationship exists in the first place. WordPress’s own historical development documentation describes the processing chain as Imagick → ImageMagick → Ghostscript for PDF support. (WordPress Trac)

That architecture creates an important security boundary:

WordPress
   |
   v
WP_Image_Editor_Imagick
   |
   v
PHP Imagick extension
   |
   v
ImageMagick
   |
   +---- PNG/JPEG decoder
   |
   +---- PDF/PostScript handling
              |
              v
          Ghostscript
              |
              v
        System-level parsing

If WordPress believes it is processing an ordinary image but ImageMagick identifies the underlying bytes as PostScript, the request can move into a completely different parser.

This is the core reason the filename alone cannot be treated as a security boundary.

The extension was the wrong thing to trust

The vulnerable logic sits around WP_Image_Editor_Imagick::load(), the WordPress image-editor path responsible for loading a file into Imagick.

There is an important difference between syntactic identity and content identity.

The syntactic identity is what the filename claims:

photo.png

The content identity is what the bytes actually contain.

A real PNG begins with a PNG signature. A PostScript document has its own identifying syntax. A PDF normally begins with the %PDF- signature. Those signatures are fundamentally different.

ImageMagick performs its own format detection based on the content it receives. Consequently, renaming a PostScript document from:

payload.ps

to:

payload.png

does not magically turn it into a PNG.

That difference is exactly what makes this vulnerability interesting. WordPress’s application-level upload checks and ImageMagick’s content-level format detection were not consistently aligned across all file-ingestion paths.

The patched implementation changes the loading process so that WordPress examines the file’s actual leading bytes before creating the Imagick object. The fix specifically accounts for dangerous PostScript and EPS signatures, validates PDF signatures, and handles compressed formats that ImageMagick may otherwise unpack automatically.

Why wp_check_filetype_and_ext() was not enough

WordPress already has a security-oriented function called wp_check_filetype_and_ext().

Its purpose is important. WordPress does not simply want to know whether a filename ends in .png; it also performs additional checks to determine whether the file actually resembles the claimed type.

For the normal media-upload path, this provides a significant layer of protection. The problem is that WordPress contains multiple ways of creating or importing media. A security check is only useful when every relevant path actually reaches it.

According to the vulnerability details, two paths were particularly important: the XML-RPC wp.uploadFile method and the cover-art extraction process associated with uploaded MP3 files. These paths can write uploaded bytes through wp_upload_bits(), bypassing the normal content inspection that occurs during a standard media upload.

Conceptually, the difference looks like this:

Normal upload
User
 |
 v
Media upload handling
 |
 v
wp_check_filetype_and_ext()
 |
 v
Validated file
 |
 v
Image processing
Problematic path
User
 |
 v
Alternate media-ingestion path
 |
 v
wp_upload_bits()
 |
 v
File written
 |
 v
Imagick processing
 |
 v
Content interpreted according to actual format

A security control placed at one entry point does not protect a downstream component if another entry point can reach that component without passing through the same validation.

How the malicious PNG reaches Ghostscript

The attack does not require ImageMagick to be tricked into believing that PostScript is a PNG. In fact, the opposite is the problem.

The attacker wants WordPress to accept the file as an upload while allowing ImageMagick to inspect the underlying bytes and recognize the content as something else.

Consider a simplified conceptual payload:

Filename:
    innocent.png
Actual content:
    PostScript data

WordPress stores the file.

Later, WordPress asks the Imagick image editor to load it. The PHP Imagick extension passes the file to ImageMagick. ImageMagick examines the content and determines that it is not actually PNG data.

If the content corresponds to a supported PostScript-family format and the server’s ImageMagick configuration permits that processing, the file can enter the PostScript delegate chain.

That is where Ghostscript becomes relevant.

Ghostscript is an interpreter rather than a simple image decoder. It has to understand the semantics of PostScript and PDF content, which historically has made it a high-value security boundary. The broader history of ImageMagick and Ghostscript vulnerabilities is commonly associated with the ImageTragick era, when attackers demonstrated that apparently harmless image-processing operations could reach dangerous delegates.

CVE-2026-65640 follows the same broad security lesson: an application that accepts an image can unintentionally expose the much larger parser ecosystem behind its image-processing library.

The filename-prefix trick

The patch also addresses another important edge case involving ImageMagick format specifiers.

ImageMagick supports explicit format prefixes in certain contexts. A filename can therefore carry information that influences which decoder ImageMagick uses.

A simplified example is:

EPS:filename.png

The important part is not the exact filename itself. The problem is that a format prefix can tell ImageMagick how to interpret the following resource.

If an application treats the entire string as an ordinary filename while ImageMagick treats part of it as a decoder directive, the application and the downstream parser are again operating under different assumptions.

The WordPress fix therefore does more than look for a .png extension. It strips and validates these prefixes before handing the resource to Imagick. The implementation also has to distinguish these prefixes from legitimate operating-system syntax, such as Windows drive letters.

That is a subtle but important security detail. A simplistic filter that rejects every string containing a colon could break legitimate Windows paths while still failing to model how ImageMagick actually interprets resource identifiers.

Remote URLs and streams matter too

The same class of problem is not limited to a local filename. Image-processing libraries can operate on resources obtained from URLs or streams, depending on the application and its configuration. If validation is based exclusively on a filename, there may not even be a meaningful filename to validate.

The patched logic consequently applies the format validation to the resource itself rather than relying exclusively on its name.

This is the right security model for parser boundaries: validate what the parser is going to consume, not what the application wishes the resource were.

Why compressed files are part of the fix

Another detail in the patch is handling of compressed content.

ImageMagick supports compressed formats and can transparently decompress certain inputs before processing them. From an application developer’s perspective, that behavior is convenient. From a security perspective, it creates another layer between the original upload and the final parser.

For example:

Uploaded bytes
     |
     v
Compression layer
     |
     v
Decompressed content
     |
     v
Format detection
     |
     v
Delegate
     |
     v
Parser

If WordPress validates only the first obvious representation of the file but ImageMagick subsequently unwraps another representation, the validation decision may no longer describe what the downstream parser receives.

The 7.0.4 fix therefore expands the inspection logic to account for compressed inputs that ImageMagick can transparently unpack.

The goal is straightforward: prevent a file that ultimately resolves to a dangerous PostScript-family payload from being treated as a harmless image simply because the dangerous content was hidden behind another representation.

What an actual attack requires

CVE-2026-65640 should not be described as an Internet-wide unauthenticated WordPress RCE. The attacker needs an authenticated WordPress account with Author-level permissions or higher. That significantly changes the threat model. An attacker cannot simply send a request to an arbitrary WordPress site and execute code without credentials.

The vulnerability becomes much more interesting on installations where Author-level accounts are routinely issued to people outside the core administrative team. That includes multi-author publications, client-managed websites, membership installations, community sites, educational platforms, and other environments where users are deliberately given the ability to upload media.

Once the attacker has the required account, the malicious file becomes the important part of the attack. The attacker uploads or otherwise introduces the crafted content through a vulnerable media-processing path and waits for WordPress to invoke Imagick against it.

If the server has the affected ImageMagick/Ghostscript processing chain available and its configuration allows the relevant operation, execution occurs under the privileges of the web-server process. That last point is important. Remote code execution does not automatically mean root access.

If PHP-FPM or Apache is running as an unprivileged service account, the initial process execution normally inherits those privileges. The attacker would then need a separate local privilege-escalation vulnerability, weak permissions, exposed credentials, misconfigured services, or another path to move from web-server access to root.

On a poorly isolated server, however, compromising the web process can still be enough to compromise the application, read configuration files, access database credentials, modify WordPress files, steal secrets, and potentially move deeper into the infrastructure.

Why this is more serious on shared hosting

The impact is also heavily dependent on the server architecture. A WordPress site running inside a properly isolated container with a dedicated service account presents a very different post-exploitation environment from several WordPress installations running under the same Unix account.

If the web process can read files belonging to other applications, access deployment credentials, reach internal services, or write outside the expected WordPress directory, the consequences of RCE increase substantially.

This is why the CVSS-style description of a vulnerability alone is not enough to understand operational risk. The same application-level flaw can have very different consequences depending on filesystem permissions, process isolation, network segmentation, PHP configuration, containerization, and the privileges assigned to the WordPress service.

What WordPress changed in 7.0.4

The security fix changes the Imagick loading process so that WordPress examines the content before constructing an Imagick object.

The patch is designed to prevent several variations of the same underlying problem.

It checks for PostScript and EPS signatures, verifies that purported PDF content actually has the expected %PDF- header, detects compressed inputs that may otherwise be unpacked by ImageMagick, and handles ImageMagick format prefixes before the resource reaches the image-processing layer.

The security principle is much clearer after the change:

Upload
  |
  v
Inspect actual content
  |
  +---- dangerous format --> reject
  |
  +---- suspicious prefix --> reject/normalize
  |
  +---- compressed dangerous content --> reject
  |
  v
Create Imagick object
  |
  v
Process image

The ordering matters.

The vulnerable design effectively allowed the application to reach the parser before it had established that the parser was being given an acceptable type of content. The corrected design performs the security decision first.

That is a meaningful architectural improvement because it moves the trust boundary closer to the actual parser invocation.

The Ghostscript angle

Ghostscript deserves particular attention because it is the component that turns this from an ordinary malformed-image problem into a potential code-execution problem.

PostScript is a programming language. A PostScript interpreter does not merely decode pixels from a static bitmap. It evaluates instructions. That is fundamentally different from processing a PNG file, where the application expects to decode structured image data.

The historical security problem around Ghostscript has repeatedly involved unsafe operations available through the PostScript/PDF language or vulnerabilities in the interpreter and its sandboxing mechanisms. Image-processing applications that automatically pass untrusted documents to Ghostscript therefore need to treat the interpreter as a security-sensitive component.

WordPress does not itself implement a PostScript interpreter. The danger arises because the WordPress media stack can eventually cause ImageMagick to invoke one. A WordPress installation using GD instead of Imagick, for example, does not have the same ImageMagick/Ghostscript processing chain. Conversely, an installation with Imagick and a permissive ImageMagick configuration has a larger parser surface.

This is not simply an “ImageMagick bug”

It would be misleading to reduce CVE-2026-65640 to “ImageMagick executes a malicious PNG.”

The vulnerability is a cross-component trust-boundary problem.

Several components participate:

WordPress upload handling
        |
        v
WordPress file validation
        |
        v
WP_Image_Editor_Imagick
        |
        v
PHP Imagick
        |
        v
ImageMagick format detection
        |
        v
Delegate selection
        |
        v
Ghostscript

Each layer has its own understanding of the resource.

WordPress sees a user-uploaded file. Imagick sees an image-processing request. ImageMagick identifies the actual format. Ghostscript sees executable document-language content. The security failure happens when the upper layer’s assumptions are weaker than the lower layer’s capabilities.

This is a recurring pattern in security engineering. A file format that looks harmless at the application layer can become dangerous when handed to a general-purpose parser capable of interpreting a much richer language.

What administrators should check

The first and most important action is to update WordPress to the patched release.

WordPress 7.0.4 release information

WordPress has historically used automatic background updates for security releases, but administrators should not assume that an update succeeded simply because automatic updates are enabled. The release archive also notes that only the latest release in an active branch should be considered safe to run and actively maintained.

After updating, administrators of sites that allow Author-level accounts should also review recent media activity. The useful question is not simply “did someone upload a PNG?” but whether an unexpected user introduced unusual files through WordPress’s media-related functionality.

A compromised WordPress installation should be treated as potentially more serious than a single modified image. If exploitation occurred, an attacker may have had the same filesystem permissions as the PHP process and could have modified plugins, themes, WordPress core files, configuration files, scheduled tasks, or other writable locations.

For incident response, administrators should compare WordPress core files against a known-good release, inspect recently modified PHP files, review WordPress authentication and upload logs, examine web-server and PHP-FPM logs, check for unexpected administrator accounts, and look for changes to wp-config.php, plugins, themes, cron configuration, and other persistence locations.

If there is credible evidence of exploitation, simply replacing the WordPress core files is not sufficient. The investigation should determine whether credentials or application secrets were exposed and whether persistence was established elsewhere on the host.

Can a WAF stop this attack?

A Web Application Firewall can reduce exposure, but it should not be treated as the primary fix. he dangerous input is ultimately a file that WordPress accepts and later processes. Depending on the upload mechanism and how the WAF inspects multipart requests, detecting a malicious PostScript payload inside an apparently valid media upload can be difficult.

A WAF may help identify suspicious upload behavior, unexpected XML-RPC activity, malicious request patterns, or known exploit attempts. It cannot, however, repair the vulnerable application logic.

The proper order is:

patch WordPress first, restrict unnecessary upload privileges second, and use WAF and host-level controls as additional layers.

Who is most exposed?

The highest practical concern is not every WordPress site on the Internet. It is the subset of sites that combine the vulnerable WordPress versions with the relevant image-processing environment and users who can upload content. A small personal site where only the administrator has an account presents a considerably smaller attack surface than a publication where dozens of external authors have upload privileges.

At the same time, calling it harmless because an attacker needs an account would also miss the point. Author accounts are often deliberately less protected than administrator accounts, and credentials for lower-privileged accounts can be obtained through phishing, password reuse, compromised email accounts, credential stuffing, malicious plugins, or other unrelated security failures.

The vulnerability therefore provides a potentially serious second-stage primitive: once an attacker obtains an Author-level account, the media upload capability can become a route into server-side execution.

The larger security lesson

CVE-2026-65640 is a good example of why file-upload security cannot be reduced to checking extensions. A file upload is not inherently safe because it ends in .png. The security question is what the entire processing pipeline will do with those bytes.

A modern web application may take an uploaded file through MIME detection, decompression, thumbnail generation, metadata extraction, format conversion, antivirus scanning, document parsing, and multiple external libraries before the operation finishes. Every additional parser introduces another trust boundary.

ImageMagick is powerful precisely because it understands many formats. That same flexibility means applications must be careful about which formats are allowed to reach it and which delegates are enabled behind it.

WordPress’s fix takes the correct approach by inspecting the underlying content before handing the file to Imagick. It also addresses less obvious input forms, including format prefixes, compressed representations, remote resources, and alternate upload paths.

That is the part administrators should take away from this vulnerability. The problem was not simply that someone could name a file something.png. The problem was that an attacker-controlled file could cross several layers of processing while each layer made a different assumption about what the file represented.

Once that file reached a parser capable of interpreting PostScript through Ghostscript, the security boundary had moved far beyond the WordPress Media Library.

Bottom line

CVE-2026-65640 is a serious authenticated RCE affecting WordPress installations that use the vulnerable Imagick/Ghostscript processing path. An Author-level user or higher can potentially abuse a crafted upload whose filename disguises its underlying content, causing WordPress to pass attacker-controlled data into ImageMagick and, under the relevant conditions, into Ghostscript.

The vulnerability does not mean every WordPress site can be remotely compromised without authentication, nor does successful exploitation automatically provide root privileges. The actual impact depends on the attacker’s account, the media-processing configuration, the privileges of the WordPress/PHP process, and the isolation of the underlying server.

For administrators, however, the decision is simple: install WordPress 7.0.4, verify that the update actually completed, and review the exposure of Author-level accounts and media-upload functionality.

The release closes a subtle but dangerous trust-boundary failure in one of the most security-sensitive parts of a CMS: accepting untrusted files and sending them to a general-purpose parser. (WordPress.org)