WordPress Core Authenticated Author+ File Type Confusion to Remote Code Execution via Imagick/Ghostscript

CVE-2026-65640 is a file-type-confusion vulnerability in WordPress core (versions 4.7.0 through 7.0.3) that lets an authenticated Author-or-above user achieve remote code execution on servers running both Imagick and Ghostscript. The attack abuses the gap between WordPress's extension-based file validation and ImageMagick's content-based detection: a PostScript payload named holiday.png passes WordPress's checks, but ImageMagick recognizes the embedded PostScript and delegates to Ghostscript — a full interpreter — which executes the attacker's code. Two bypass paths skip even wp_check_filetype_and_ext(): the XML-RPC wp.uploadFile method and the MP3 cover-art extraction routine, both of which call wp_upload_bits() directly without content inspection. WordPress 7.0.4 (and 23 backported branch releases) patch the issue by inspecting the first chunk of every upload for PostScript/EPS signatures.

Multiple sources cite a CVSS 8.8 HIGH (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H); Patchstack independently scored it 9.1 but simultaneously labeled exploitation 'unlikely' due to the Author privilege requirement and dual-dependency on Imagick+Ghostscript. That tension is telling: the *outcome* is full RCE, but the *entry cost* is non-trivial. The vendor's HIGH label is directionally correct but slightly overweights the theoretical path and underweights the real-world friction of needing both an Author account and a specific server-side image stack.

Why this verdict

• Authentication gate: PR:L means the attacker needs a valid Author+ account. This eliminates drive-by exploitation by anonymous scanners and reduces the reachable population to multi-author sites or sites with compromised credentials — a meaningful narrowing from the 43.5% of all websites running WordPress.
• Dual server-side dependency: Both Imagick *and* Ghostscript must be installed and reachable. Many managed hosts default to GD, and post-2018 ImageMagick policy.xml hardening disables Ghostscript delegation on security-conscious deployments. This further narrows the exploitable population, likely to 20-40% of the total WordPress base.
• No PoC, no exploitation: As of 48 hours post-disclosure, there is no public PoC and no observed in-the-wild exploitation. The technical details (XML-RPC bypass, MP3 cover-art path) are now public, so weaponization timeline is weeks, not months.
• Role multiplier: WordPress is overwhelmingly deployed as a line-of-business web application server (typical role). It is not a domain controller, hypervisor, identity provider, or other fleet-scale high-value target. RCE lands as the unprivileged web server user (www-data), and blast radius is typically host-level or tenant-level. On containerized deployments, blast radius is further limited to the container. However, WordPress *does* hold database credentials (wp-config.php) and may be the public face of an organization — compromise enables data exfiltration and defacement, keeping the floor at HIGH.
• Massive install base multiplier: Even a narrow exploitable fraction of 43.5% of all websites is still millions of hosts. The sheer population at risk keeps this firmly in HIGH territory despite the friction.

Why not higher?

CRITICAL would require either unauthenticated access, active exploitation, or a high-value-role deployment pattern. This CVE requires authenticated Author+ access (not unauthenticated), has no PoC or exploitation in the wild, and WordPress is not a canonical high-value-role component (it's a web application, not a DC/hypervisor/IdP/PAM). The web server user context (www-data) limits immediate blast radius to the host or container, not fleet-scale compromise.

Why not lower?

The outcome is full RCE on a production web server — the most severe impact class short of kernel compromise. WordPress's enormous installed base means even a narrowed population is millions of potential targets. The XML-RPC and MP3 cover-art bypass paths lower attack complexity once credentials are obtained. Public technical details will accelerate weaponization. MEDIUM would understate the risk for any organization running multi-author WordPress on Imagick+Ghostscript stacks.

1. Disable Ghostscript delegation in ImageMagick policy.xml — Add <policy domain="delegate" rights="none" pattern="gs" /> and <policy domain="coder" rights="none" pattern="{PS,EPS,PDF,XPS}" /> to /etc/ImageMagick-6/policy.xml (or -7). This breaks the exploit chain at step 3 regardless of WordPress version. Deploy within 30 days per noisgate mitigation SLA for HIGH.
2. Switch WordPress image editor to GD — Add add_filter('wp_image_editors', function(){ return ['WP_Image_Editor_GD']; }); to wp-config.php or a must-use plugin. GD does not delegate to Ghostscript. This eliminates the vulnerability entirely on affected hosts. Deploy within 30 days.
3. Disable XML-RPC — Block or disable XML-RPC via .htaccess, web server config, or a security plugin. This closes the wp.uploadFile bypass path that skips wp_check_filetype_and_ext(). Many sites have no legitimate XML-RPC need.
4. Restrict Author role upload capabilities — Use a capability manager plugin to remove upload_files from the Author role, or restrict allowed upload MIME types to exclude formats that could carry PostScript payloads. This raises the privilege bar to Editor/Admin only.
5. Deploy WAF rules blocking PostScript in uploads — Configure your WAF (Cloudflare, Sucuri, ModSecurity) to inspect upload request bodies for PostScript signatures (%!PS-Adobe, %!FontType, %PDF-) in files with image extensions. Patchstack has deployed a best-effort virtual patch.

Run this script on each WordPress host as root or the web server user. It checks whether the WordPress version is patched AND whether Imagick+Ghostscript are both available to the web process. Usage: sudo bash check_cve_2026_65640.sh /var/www/html (pass the WordPress root directory as the first argument).

#!/usr/bin/env bash
# check_cve_2026_65640.sh — Detect CVE-2026-65640 exposure
# Usage: bash check_cve_2026_65640.sh /path/to/wordpress
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

WP_ROOT="${1:?Usage: $0 /path/to/wordpress}"
VERSION_FILE="$WP_ROOT/wp-includes/version.php"

if [[ ! -f "$VERSION_FILE" ]]; then
  echo "UNKNOWN — $VERSION_FILE not found. Is this a WordPress installation?"
  exit 2
fi

# Extract WordPress version
WP_VERSION=$(grep -oP "\\\$wp_version\s*=\s*'\K[^']+" "$VERSION_FILE" 2>/dev/null || true)
if [[ -z "$WP_VERSION" ]]; then
  echo "UNKNOWN — could not parse WordPress version from $VERSION_FILE"
  exit 2
fi

echo "WordPress version: $WP_VERSION"

# Check if Imagick PHP extension is loaded
IMAGICK_LOADED=false
if php -m 2>/dev/null | grep -qi imagick; then
  IMAGICK_LOADED=true
  echo "Imagick PHP extension: LOADED"
else
  echo "Imagick PHP extension: NOT LOADED"
fi

# Check if Ghostscript is available
GS_AVAILABLE=false
if command -v gs &>/dev/null; then
  GS_AVAILABLE=true
  GS_VERSION=$(gs --version 2>/dev/null || echo 'unknown')
  echo "Ghostscript: INSTALLED (version $GS_VERSION)"
else
  echo "Ghostscript: NOT INSTALLED"
fi

# Check ImageMagick policy for PS/EPS delegation
POLICY_BLOCKS_GS=false
for POLICY_FILE in /etc/ImageMagick-*/policy.xml /usr/local/etc/ImageMagick-*/policy.xml; do
  if [[ -f "$POLICY_FILE" ]]; then
    if grep -qiE 'pattern="(gs|PS|EPS)".*rights="none"' "$POLICY_FILE" 2>/dev/null; then
      POLICY_BLOCKS_GS=true
      echo "ImageMagick policy ($POLICY_FILE): BLOCKS Ghostscript delegation"
    fi
  fi
done

# Version comparison: patched versions for the 7.0.x branch
# Patched = 7.0.4+, or any of the backported releases
version_gte() {
  printf '%s\n%s' "$2" "$1" | sort -V -C
}

PATCHED=false
# Check major branch patched versions
if version_gte "$WP_VERSION" "7.0.4" 2>/dev/null; then
  PATCHED=true
elif [[ "$WP_VERSION" =~ ^6\.9\. ]] && version_gte "$WP_VERSION" "6.9.7"; then
  PATCHED=true
elif [[ "$WP_VERSION" =~ ^6\.8\. ]] && version_gte "$WP_VERSION" "6.8.8"; then
  PATCHED=true
elif [[ "$WP_VERSION" =~ ^6\.7\. ]] && version_gte "$WP_VERSION" "6.7.7"; then
  PATCHED=true
elif [[ "$WP_VERSION" =~ ^4\.[0-6]\. ]] || [[ "$WP_VERSION" =~ ^[123]\. ]]; then
  # Versions before 4.7 are not affected
  PATCHED=true
fi

echo ""
if $PATCHED; then
  echo "PATCHED — WordPress $WP_VERSION includes the fix for CVE-2026-65640."
  exit 0
elif ! $IMAGICK_LOADED || ! $GS_AVAILABLE; then
  echo "PATCHED (by configuration) — WordPress $WP_VERSION is unpatched, but Imagick+Ghostscript are not both present. Exploit chain cannot complete."
  exit 0
elif $POLICY_BLOCKS_GS; then
  echo "PATCHED (by policy) — WordPress $WP_VERSION is unpatched, but ImageMagick policy blocks Ghostscript delegation."
  exit 0
else
  echo "VULNERABLE — WordPress $WP_VERSION with Imagick+Ghostscript active. Apply update or compensating controls immediately."
  exit 1
fi

Sources

1. WordPress 7.0.4 Release Announcement
2. CyberSecurity News — WordPress Imagick RCE Vulnerability
3. Wordify — WordPress 7.0.4 Security Release Analysis
4. MagicWP — WordPress 7.0.4 Patches CVE-2026-65640
5. Patchstack — WordPress Core File Type Confusion to RCE
6. Reclaim Hosting — WordPress RCE Advisory
7. Feedly CVE Intelligence — CVE-2026-65640