WordPress 7.0.4 Fixes a High-Severity RCE Vulnerability: ThreatShield Protection Is Already Live

Monarx Threat Research Team

‍

WordPress has released WordPress 7.0.4 to address a newly disclosed high-severity vulnerability in WordPress core that could allow an authenticated attacker to achieve remote code execution.

Security fixes are available for affected WordPress branches dating back to version 4.7. This is a separate issue from the pre-authentication XSS vulnerability fixed in WordPress 7.0.3.

For hosting providers, the important part is how this vulnerability works. The attack can be delivered through content that appears to be a legitimate PDF or image upload and is then processed after it reaches the application.

ThreatShield protection against the known exploitation paths is already deployed.

How the vulnerability works

The vulnerability could allow an authenticated WordPress user with Author-level access or higher to upload specially crafted content presented as a PDF or an image format.

The vulnerable code lives in WP_Image_Editor_Imagick, the class WordPress core uses to generate thumbnails whenever media is uploaded. Before 7.0.4 this class decided how to handle a file almost entirely by trusting its extension. PDF got routed to PDF handling and PNG/JPG got routed to standard image handling. ImageMagick doesn't work that way, it inspects the file's real content and hands off to whichever backend matches. This mismatch is the root cause of the issue.

If you upload a file the normal way, through the Media Library for example, WordPress actually checks the file content and extension, if there's a mismatch it rejects the upload before it even touches the disk. However before 7.0.4 two upload paths skipped this check entirely, wp.uploadFile and the MP3 cover art extraction. Neither of these goes through the normal check, so if an attacker uploads a file named report.pdf or holiday.jpg that's actually a PostScript program, WordPress immediately generates a thumbnail for it and WP_Image_Editor_Imagick::load() opens the file and ImageMagick sniffs its real format and when the format turns out to be PostScript instead of the PDF or image, ImageMagick hands it off to GhostScript, which runs it as a program.

Under vulnerable conditions, attackers could abuse this processing path to achieve remote code execution.

Why this one is harder for a traditional WAF

This is not a typical request-based web attack.

The malicious behavior can sit inside content that initially looks like a legitimate media upload and only becomes dangerous when the file is processed later by components such as Imagick and Ghostscript.

That makes protection more difficult for a conventional WAF and heavily dependent on its file inspection capabilities and configuration.

ThreatShield adds another layer. Instead of looking only at the original request, ThreatShield monitors application behavior at runtime, helping identify and block the known exploitation paths as they happen.

You should still update WordPress

ThreatShield helps protect the window between vulnerability disclosure and complete patch deployment, but it does not replace the official WordPress security update.

Hosting providers should:

• Confirm ThreatShield is enabled and configured to block
• Prioritize the appropriate WordPress security releases across managed environments
• Notify customers who manage their own WordPress updates and encourage them to update quickly
• Make sure automatic WordPress core security updates are working wherever you rely on them

For a hosting provider managing thousands or millions of WordPress sites, deploying a patch everywhere does not happen instantly.

Some customers manage their own updates. Some have automatic updates disabled. Some environments need additional testing before changes can be rolled out.

The vulnerability is public. The patch is available. But there is still a window where sites may remain exposed.

That is exactly the gap ThreatShield is designed to help cover.

Not using ThreatShield yet?

New vulnerabilities are disclosed all the time. The challenge for hosting providers is not only knowing they exist. It is protecting customers during the time it takes to update an entire fleet.

ThreatShield adds runtime protection against emerging exploitation techniques while patches are still being rolled out.

Protections can be deployed automatically, without requiring your security or operations teams to build, test, and distribute individual rules every time a new vulnerability appears.

For the WordPress 7.0.4 vulnerability, ThreatShield protection against the known exploitation paths is already live.

You should still patch WordPress as quickly as possible.

But while updates are making their way across your infrastructure, ThreatShield gives you another layer of protection.

‍

See how ThreatShield can help protect your WordPress fleet against emerging threats.

‍