WordPress 6

CVE-2026-63030 is a route-confusion flaw in the WordPress REST API /wp/v2/batch/v1 endpoint. The batch handler resolves sub-request routes correctly but re-uses the *outer* request's permission context when dispatching them, so authorization checks that should fire on each nested route silently pass. The result is unauthenticated read access to REST endpoints that were supposed to require edit_posts, manage_options, or higher — including draft/private content, user metadata, and internal option leakage. Affected versions are WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1; fixed in 6.9.5, 7.0.2, and backported to 6.8.6 and 7.1 Beta 2.

The vendor's HIGH (7.5, C:H only) rating is technically defensible for the isolated bug — no integrity or availability impact in a vacuum. But it understates real-world blast radius. WordPress's own advisory ties this route-confusion to CVE-2026-60137 (the batch-endpoint SQLi dubbed *wp2shell*), and when persistent object cache is absent the pair yields unauthenticated RCE. Given WordPress's ~43% share of all websites and the fact that Automattic is force-pushing auto-updates, the operational severity is CRITICAL, not HIGH.

Why this verdict

• Unauthenticated + network + AC:L — no friction on initial access; a single POST reaches the primitive.
• Role multiplier: WordPress is canonically the public web edge and frequently the WooCommerce data plane. High-value-role share is effectively 100% of the affected base — every install IS the role. Blast radius on successful chain: site defacement, credential theft, checkout skimmer injection, pivot to hosting account.
• Chain partner is disclosed and PoC'd. CVE-2026-60137 (SQLi) uses the same permission bypass. wp2shell PoC weaponizes both.
• Active exploitation the day of disclosure (Cloudflare blog, TheHackerNews). Auto-update is being force-pushed BY THE VENDOR — that's a HIGH-severity-class signal from Automattic themselves.
• Friction credit: managed hosts with Redis/Memcached blunt the RCE chain to information-disclosure only. That's still C:H unauth on private posts / user emails / secret keys — not a downgrade.

Why not higher?

Already at CRITICAL 9.3. Score is not 10.0 because managed hosts running persistent object cache (WP.com, WP Engine, Pantheon — a meaningful minority of installs) break the RCE chain, leaving only the confidentiality primitive. Also, WordPress auto-update mechanism will remediate a large fraction of the install base automatically within days.

Why not lower?

Downgrading to HIGH would require the vendor's C:H-only framing to hold in the wild, but it does not: the chain partner (CVE-2026-60137) is public, the PoC (wp2shell) is public, and active exploitation is confirmed. On a ~43%-of-web install base, HIGH understates the operational threat. The Deployment-Role Blast Radius floor is CRITICAL because 100% of installs occupy the canonical public-web role.

1. Force WordPress core auto-update NOW — Set WP_AUTO_UPDATE_CORE=true in wp-config.php on every host; run wp core update via WP-CLI for fleets. Deploy within 3 days per noisgate mitigation SLA — but given active exploitation, treat as hours, not days.
2. Block /wp-json/wp/v2/batch/v1 at the WAF/edge — Cloudflare, Akamai, and AWS WAF shipped managed rules on 2026-07-17. If you can't patch immediately, drop POST to that path from non-authenticated sessions. Deploy within hours.
3. Deploy a persistent object cache — Install Redis or Memcached with a WP object-cache drop-in. This breaks the RCE chain (CVE-2026-60137 requires the non-cached code path). Doesn't fix the info-disclosure but removes the worst outcome. Deploy within 3 days.
4. Set DISALLOW_FILE_EDIT=true in wp-config.php — Kills the theme/plugin editor RCE path even if an attacker recovers admin session. Zero-cost, deploy fleet-wide within 24h.
5. Rotate WordPress secret keys and force password reset for all admins — Assume wp_options and wp_users disclosure occurred if the site was exposed and unpatched between 2025-12-02 (6.9.0 release) and your patch time. Regenerate keys via https://api.wordpress.org/secret-key/1.1/salt/ within 7 days.

Run on the WordPress host as any user with read access to wp-includes/version.php, or against a remote target as an unauthenticated auditor. Example: ./check-cve-2026-63030.sh /var/www/html for local check, or ./check-cve-2026-63030.sh https://site.example.com for remote probe. No privileges needed for remote mode; read-only file access for local.

#!/usr/bin/env bash
# noisgate verifier — CVE-2026-63030 (WordPress REST batch route confusion)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "UNKNOWN: usage: $0 <wp-root-path | https://site>" >&2
  exit 2
fi

vercmp() {
  # returns 0 if $1 >= $2
  [[ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" == "$2" ]]
}

check_version() {
  local v="$1"
  # Fixed lines: 6.8.6+, 6.9.5+, 7.0.2+, 7.1+
  local major_minor="${v%.*}"
  case "$major_minor" in
    6.8) vercmp "$v" "6.8.6" && return 0 || return 1 ;;
    6.9) vercmp "$v" "6.9.5" && return 0 || return 1 ;;
    7.0) vercmp "$v" "7.0.2" && return 0 || return 1 ;;
    *)  vercmp "$v" "7.1"   && return 0 || return 1 ;;
  esac
}

if [[ "$TARGET" =~ ^https?:// ]]; then
  # Remote probe
  BODY=$(curl -sk --max-time 10 "${TARGET%/}/?rest_route=/" || true)
  VER=$(curl -sk --max-time 10 "${TARGET%/}/wp-login.php" | grep -oiE 'ver=[0-9]+\.[0-9]+(\.[0-9]+)?' | head -1 | cut -d= -f2)
  if [[ -z "$VER" ]]; then
    echo "UNKNOWN: could not fingerprint WordPress version at $TARGET"
    exit 2
  fi
else
  # Local file check
  VF="$TARGET/wp-includes/version.php"
  if [[ ! -r "$VF" ]]; then
    echo "UNKNOWN: $VF not readable"
    exit 2
  fi
  VER=$(grep -E "^\\\$wp_version" "$VF" | sed -E "s/.*=[[:space:]]*'([^']+)'.*/\\1/")
fi

echo "Detected WordPress version: $VER"
if check_version "$VER"; then
  echo "PATCHED"
  exit 0
else
  echo "VULNERABLE — upgrade to 6.8.6, 6.9.5, 7.0.2, or 7.1+"
  exit 1
fi

Sources

1. Cloudflare blog — WAF protects WordPress from two high-severity vulnerabilities
2. TheHackerNews — wp2shell WordPress core flaw
3. WordPress CVEs — cvedetails
4. Wordfence Intelligence — WP vulnerability report
5. OpenCVE — WordPress vulnerabilities
6. Feedly CVE feed — WordPress
7. W3Techs — CMS usage statistics
8. WordPress developer — REST API batch endpoint