WordPress 6

The bug lives in WP_Query: when author__not_in is passed as a string instead of an array, the is_array() sanitisation branch is skipped, (array)"payload" wraps it as ["payload"], and implode(',', ...) drops the attacker's raw string straight into a NOT IN (...) clause. Affected branches: 6.8.x < 6.8.6, 6.9.x < 6.9.5, and 7.0.x < 7.0.2. In isolation the REST API's author_exclude schema (type: array, items: integer) is supposed to block string values before they ever reach the vulnerable path — which is why WordPress scored it MEDIUM and set AC:H.

That MEDIUM label is wrong for anyone running WordPress 6.9 or 7.0. Adam Kues (Searchlight Cyber / Assetnote) disclosed this alongside CVE-2026-63030, a REST batch-route confusion bug that dispatches a categories request through the posts controller and bypasses the schema check entirely. Chained, an unauthenticated attacker gets SQLi → object-injection → pre-auth RCE on a stock WordPress install. A public PoC (Senanfurkan/wordpress-cve-2026-63030) landed the same day, and Cloudflare shipped emergency WAF signatures within 24 hours. Treat this CVE ID as the SQLi half of WP2Shell — not a standalone medium.

Why this verdict

• Chain flips the CVSS: standalone AC:H/C:H/I:N/A:N is fair, but chained with CVE-2026-63030 the attack complexity collapses to AC:L and impact expands to C:H/I:H/A:H. A CVE ID is not a threat model.
• Role multiplier — public-facing web tier: WordPress is canonically the internet-facing marketing/CMS layer for a majority of enterprises. Chain succeeds → PHP-user shell → webshell → DMZ pivot. Blast radius: host → tenant → potential AD pivot where WP shares SSO. Deployment share in this role: >90% of installs are public-facing by definition — floor is CRITICAL.
• Weaponisation velocity: Public PoC same-day, WAF signatures same-day, GreyNoise tag within 48h. Mass exploitation window has already opened.
• Population is enormous: 5–6M vulnerable internet-exposed instances per Shodan/Censys facets. Even at 0.1% conversion, that is a five-figure victim count.

Why not higher?

There is no higher bucket. Score capped at 9.4 (not 10.0) because a small fraction of managed WordPress hosts (WP Engine, Kinsta, Automattic-hosted) auto-patched within hours of the 7.0.2 release, and Cloudflare WAF customers with default managed-rules had virtual patching within 24h — so real-world victim count will be materially lower than the raw exposed-population number.

Why not lower?

Downgrading below CRITICAL requires either no public exploit (there is one), narrow install base (14M+ exposed hosts), or high attacker prerequisites (chain is unauthenticated). None of the friction factors — WAF, hardening plugins, jailed PHP — apply to enough of the population to break the CRITICAL floor. Vendor MEDIUM is only defensible if you ignore the sibling CVE, which no attacker will.

1. Block /wp-json/batch/v1 at the WAF or reverse proxy — The batch endpoint is the vector for the RCE chain and is rarely used by legitimate frontend traffic. Add a deny rule for POST to that path (or return 403 for anonymous requests) at Cloudflare/Akamai/F5/nginx. Deploy within 3 days per noisgate mitigation SLA — hours if you are internet-facing.
2. Force WordPress auto-updates to minor releases — Set WP_AUTO_UPDATE_CORE = 'minor' (or true) in wp-config.php on every managed WP host. 6.8.6 / 6.9.5 / 7.0.2 will flow automatically. Combine with a scheduled wp cron event run --due-now if cron is disabled. Roll out within 3 days.
3. Enable Cloudflare / Sucuri / Wordfence emergency rules — All three vendors shipped CVE-2026-63030 / 60137 signatures on 2026-07-17. If you already pay for them, verify the ruleset version is post-disclosure and set to block, not log. Confirm rule ID coverage within 24 hours.
4. Restrict database grants on wp_users and wp_options — Even a successful SQLi is materially less useful if the DB_USER in wp-config.php cannot write to wp_options (blocks the unserialize gadget) or SELECT from wp_users (blocks credential dump). Rotate creds and constrain grants within 30 days as a systemic hardening step.

Run this from an auditor workstation with network reach to the target site. Usage: ./check-cve-2026-60137.sh https://target.example.com. No credentials required — it inspects the WordPress REST API version banner and the batch endpoint. Non-zero exit indicates VULNERABLE.

#!/usr/bin/env bash
# noisgate: CVE-2026-60137 / CVE-2026-63030 (WP2Shell) detector
# Usage: ./check-cve-2026-60137.sh https://target.example.com
set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <https://site>" >&2
  exit 2
fi

# Strip trailing slash
TARGET="${TARGET%/}"

# 1. Fetch WordPress version from /wp-json/ (public endpoint)
BODY="$(curl -sS --max-time 10 -A 'noisgate-verifier/1.0' "$TARGET/wp-json/" || true)"
VER="$(echo "$BODY" | grep -oE '"gmt_offset"|"home"' >/dev/null && \
       curl -sS --max-time 10 -A 'noisgate-verifier/1.0' "$TARGET/?rest_route=/" | \
       grep -oE 'wp-json/wp/v2[^"]*' | head -n1)"

HDR_VER="$(curl -sSI --max-time 10 "$TARGET/wp-json/" | grep -i '^x-wp-' || true)"
RAW_VER="$(curl -sS --max-time 10 "$TARGET/readme.html" | grep -oE 'Version [0-9]+\.[0-9]+(\.[0-9]+)?' | head -n1 | awk '{print $2}')"

if [[ -z "$RAW_VER" ]]; then
  echo "UNKNOWN: could not determine WordPress version at $TARGET"
  exit 3
fi

echo "Detected WordPress version: $RAW_VER"

# 2. Compare against fixed versions per branch
vuln=1  # 1 = patched, 0 = vulnerable
IFS='.' read -r MAJ MIN PATCH <<<"$RAW_VER"
PATCH="${PATCH:-0}"

case "${MAJ}.${MIN}" in
  6.8) [[ "$PATCH" -lt 6 ]] && vuln=0 ;;
  6.9) [[ "$PATCH" -lt 5 ]] && vuln=0 ;;
  7.0) [[ "$PATCH" -lt 2 ]] && vuln=0 ;;
  *)   # older branches: SQLi path predates guard; RCE chain N/A
       [[ "$MAJ" -eq 6 && "$MIN" -lt 8 ]] && { echo "PATCHED: $RAW_VER predates vulnerable code path"; exit 0; } ;;
esac

# 3. Probe batch endpoint reachability (RCE chain requires it)
BATCH_CODE="$(curl -sS -o /dev/null -w '%{http_code}' --max-time 10 \
  -X POST -H 'Content-Type: application/json' \
  --data '{"validation":"require-all-validate","requests":[]}' \
  "$TARGET/wp-json/batch/v1")"

echo "Batch endpoint returned: HTTP $BATCH_CODE"

if [[ "$vuln" -eq 0 ]]; then
  if [[ "$BATCH_CODE" =~ ^(200|400|401|403)$ && "${MAJ}.${MIN}" != "6.8" ]]; then
    echo "VULNERABLE: $RAW_VER, batch endpoint reachable — pre-auth RCE chain viable"
    exit 1
  else
    echo "VULNERABLE: $RAW_VER SQLi path present (batch route not confirmed reachable)"
    exit 1
  fi
fi

echo "PATCHED: $RAW_VER is at or above fixed release"
exit 0

Sources

1. Cloudflare Blog — WordPress WAF protection for CVE-2026-60137 / 63030
2. Beazley Security Labs — WP2Shell advisory (BSL-A1193)
3. SecurityOnline — WordPress Pre-Auth RCE CVE-2026-63030 PoC public
4. GitHub PoC — Senanfurkan/wordpress-cve-2026-63030
5. Cyber Kendra — WP2Shell critical RCE writeup
6. THREATINT — CVE-2026-60137 record
7. Feedly CVE — CVE-2026-63030 sibling record
8. WordPress security release announcement (7.0.2 / 6.9.5 / 6.8.6)