CVE-2026-65640: 
WordPress vulnerability analysis and mitigation

CVE-2026-65640 is a Remote Code Execution (RCE) vulnerability in WordPress that allows an authenticated user with Author-level privileges (or higher) to upload a malicious PostScript file and execute arbitrary code on the server. The vulnerability affects all versions of WordPress prior to 7.0.4, with the fix backported to all branches back to version 4.7. It was disclosed on August 17, 2026, and carries a CVSS v3.0 base score of 8.8 (High) (Feedly, WordPress Release, GitHub Advisory).

The root cause is classified as CWE-434 (Unrestricted Upload of File with Dangerous Type). When the Imagick PHP extension and Ghostscript are both installed and active on the server, WordPress fails to adequately restrict the processing of uploaded PostScript files. An attacker with the upload_files capability (Author role or higher) can craft a malicious PostScript file that, when processed by Imagick via Ghostscript, triggers arbitrary code execution on the web server. The attack requires no user interaction beyond the attacker's own authenticated upload action, and exploitation complexity is low (Feedly, GitHub Advisory, CyberSecurityNews).

Successful exploitation grants the attacker arbitrary code execution with the privileges of the web server process, resulting in full compromise of confidentiality, integrity, and availability of the affected system. An attacker can read sensitive files, modify or delete site content, install backdoors or web shells, and potentially pivot to other systems on the same network. Given WordPress's widespread deployment, the blast radius is significant — any site running a vulnerable version with Imagick and Ghostscript enabled and with untrusted Author-level users is at risk of complete site takeover (Feedly, SecurityWeek).

A GitHub repository claiming to contain a PoC exploit was identified, but Feedly's analysis determined it contains no actual exploit code (only a .github directory), classifying it as non-exploitable (Feedly). Despite the absence of a confirmed working public exploit, the BLACKCOFFEE malware family and PNG_dropper malware have been associated with this vulnerability in threat intelligence reporting (Feedly). The EPSS score is currently 0.0, and there is no confirmed CISA KEV catalog listing at this time. Exploitation requires authenticated access at the Author level or above, which limits opportunistic mass exploitation but remains a realistic threat in multi-user WordPress environments.

1. Reconnaissance: Identify WordPress sites running versions prior to 7.0.4 using tools like WPScan or Shodan. Confirm that the target uses Imagick and Ghostscript by probing server responses or reviewing publicly accessible configuration indicators.
2. Obtain Author-level credentials: Acquire valid credentials for an account with the upload_files capability (Author role or higher) via phishing, credential stuffing, or by registering if open registration is enabled.
3. Craft malicious PostScript file: Create a specially crafted PostScript (.ps) file containing embedded commands designed to execute arbitrary code when processed by Ghostscript. The file may be disguised with an image-like name or extension to evade basic filters.
4. Upload the malicious file: Log in to the WordPress dashboard and navigate to the Media Library upload function. Upload the crafted PostScript file through the standard media upload interface.
5. Trigger server-side processing: WordPress passes the uploaded file to Imagick for thumbnail generation or metadata extraction. Imagick delegates PostScript processing to Ghostscript, which executes the embedded malicious commands with web server process privileges.
6. Achieve code execution: The attacker's payload executes on the server — enabling reverse shell establishment, web shell deployment, credential harvesting, or lateral movement (Feedly, GitHub Advisory).

• Network: Outbound connections from the web server process to unexpected external IPs or domains following a file upload event; unusual DNS lookups initiated by the PHP/web server process.
• File System: Presence of unexpected .ps or disguised PostScript files in the WordPress uploads directory (/wp-content/uploads/); newly created web shells (e.g., .php files) in the uploads or themes directories; unexpected cron jobs or scheduled tasks created under the web server user account.
• Logs: WordPress access logs showing POST requests to /wp-admin/async-upload.php or /wp-json/wp/v2/media with PostScript file uploads from Author-level accounts; PHP error logs showing Ghostscript or Imagick execution errors or unexpected command output; web server logs showing unusual child process spawning.
• Process: Unexpected child processes spawned by the web server (e.g., gs, bash, curl, wget, python) following a media upload event; processes running under the web server user (e.g., www-data) performing network connections or file writes outside normal paths (Feedly, CyberSecurityNews).

Update WordPress to version 7.0.4 or apply the backported security fix available for all branches back to version 4.7 (WordPress Release). As a configuration-based workaround, restrict the upload_files capability to only fully trusted users, and if PostScript processing is not required, disable Imagick/Ghostscript handling of PostScript files by modifying the Ghostscript policy file (/etc/ImageMagick-*/policy.xml) to deny read/write access to the PS, EPS, PDF, and XPS coders. Cloudflare has also released WAF rules to help detect and block exploitation attempts (Cloudflare WAF).

The WordPress team released version 7.0.4 promptly and backported the fix to all supported branches, demonstrating a broad response to the severity of the issue (WordPress Release). SecurityWeek and CyberSecurityNews covered the vulnerability extensively, highlighting the risk to multi-author WordPress sites (SecurityWeek, CyberSecurityNews). Security researchers on Mastodon (infosec.exchange) flagged the issue quickly, and The Hacker News included it in their weekly recap, indicating broad community awareness (The Hacker News). Hosting providers such as Liquid Web posted incident notices, and Cloudflare deployed WAF protections, reflecting the urgency felt across the industry (Cloudflare WAF).