Improper Neutralization of Input During Web Page Generation

CVE-2025-22308 is a stored XSS flaw in the WordPress Smart Custom Fields plugin. Authoritative WordPress security sources track it as affecting versions through 5.0.0, with the fix in 5.0.1. In plain English: a user who already has at least Contributor access can plant script content into a page or field handled by the plugin, and that script runs later when someone views the poisoned content.

The vendor-style 6.5/MEDIUM baseline is technically defensible, but it overstates enterprise urgency. The real attack chain requires authenticated access first, then a more privileged victim to render the payload, which means this is usually a post-initial-access or abused low-privilege account problem, not a clean unauthenticated internet-edge compromise. The stored nature and site-level blast radius keep it from being ignored, but the attacker-position requirement pushes it down to LOW for most 10,000-host environments.

Why this verdict

• Start from vendor 6.5, then cut for PR:L: requiring Contributor+ means this is not an internet-edge initial compromise; it already assumes account abuse or prior access.
• Cut again for UI:R: the payload still needs a privileged user to view the malicious content before it pays off.
• Blast radius is usually one WordPress site: even when it works, this is typically a single-site/admin-session problem, not an estate-wide host compromise primitive.

Why not higher?

There is no evidence of KEV listing, no confirmed in-the-wild exploitation, no widely circulated public exploit, and no unauthenticated path. In enterprise terms, this is a workflow abuse bug inside a CMS, not a perimeter-break or mass-compromise event.

Why not lower?

Stored XSS in a CMS is still materially dangerous because it can turn a low-privilege author account into administrator-level actions if the victim path lands. The plugin also has 50,000+ active installs, so this is not an obscure one-off package with near-zero real-world footprint.

1. Restrict authoring roles — Reduce or remove unnecessary Contributor accounts and disable public/self-registration where business permits. For a LOW verdict there is no mitigation SLA, so do this as backlog hygiene during your normal IAM and CMS cleanup cycle.
2. Enforce MFA and SSO on WordPress admins and authors — This vulnerability is bottlenecked by authenticated access, so stronger identity controls shrink the reachable population fast. For a LOW verdict there is no mitigation SLA, so fold this into your standard WordPress hardening program rather than emergency change windows.
3. Review content and admin activity logs — Look for unusual draft/post edits from low-privilege users followed by admin account changes, plugin setting changes, or suspicious admin-ajax activity. For a LOW verdict there is no mitigation SLA, so add these checks to your regular detection content rather than spinning up an incident sprint.
4. Disable risky admin conveniences — Turn off in-dashboard plugin/theme editing and keep privileged browser usage segmented from everyday browsing. This limits post-XSS payoff if an admin does render a poisoned page; for LOW, implement during routine hardening with no special SLA.

Run this on the WordPress host or in a container with the plugin files mounted. Invoke it as bash verify-scf-cve-2025-22308.sh /var/www/html or point directly at the plugin directory; no root is required if the web files are readable. It checks the installed smart-custom-fields version and reports VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# verify-scf-cve-2025-22308.sh
# Check whether WordPress Smart Custom Fields is vulnerable to CVE-2025-22308
# Usage:
#   bash verify-scf-cve-2025-22308.sh /var/www/html
#   bash verify-scf-cve-2025-22308.sh /var/www/html/wp-content/plugins/smart-custom-fields
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / not installed / unable to determine

set -u

TARGET="${1:-}"
if [ -z "$TARGET" ]; then
  echo "UNKNOWN - missing argument. Usage: $0 <wordpress-root|plugin-dir>"
  exit 2
fi

PLUGIN_DIR=""
if [ -d "$TARGET/wp-content/plugins/smart-custom-fields" ]; then
  PLUGIN_DIR="$TARGET/wp-content/plugins/smart-custom-fields"
elif [ -d "$TARGET" ] && [ "$(basename "$TARGET")" = "smart-custom-fields" ]; then
  PLUGIN_DIR="$TARGET"
else
  echo "UNKNOWN - Smart Custom Fields plugin directory not found under: $TARGET"
  exit 2
fi

PLUGIN_FILE=""
for f in "$PLUGIN_DIR"/*.php; do
  [ -f "$f" ] || continue
  if grep -qi '^\s*Plugin Name:\s*Smart Custom Fields' "$f" 2>/dev/null; then
    PLUGIN_FILE="$f"
    break
  fi
done

version=""
if [ -n "$PLUGIN_FILE" ]; then
  version=$(awk -F': *' 'BEGIN{IGNORECASE=1} /^Version:/ {print $2; exit}' "$PLUGIN_FILE" | tr -d '\r')
fi

if [ -z "$version" ] && [ -f "$PLUGIN_DIR/readme.txt" ]; then
  version=$(awk -F': *' 'BEGIN{IGNORECASE=1} /^Stable tag:/ {print $2; exit}' "$PLUGIN_DIR/readme.txt" | tr -d '\r')
fi

if [ -z "$version" ]; then
  echo "UNKNOWN - could not determine installed version in $PLUGIN_DIR"
  exit 2
fi

normalize_ver() {
  local v="$1"
  local IFS='.'
  local parts=($v)
  local a=${parts[0]:-0}
  local b=${parts[1]:-0}
  local c=${parts[2]:-0}
  printf '%d%03d%03d\n' "$a" "$b" "$c"
}

installed=$(normalize_ver "$version")
fixed=$(normalize_ver "5.0.1")

if [ "$installed" -lt "$fixed" ]; then
  echo "VULNERABLE - Smart Custom Fields version $version (< 5.0.1)"
  exit 1
else
  echo "PATCHED - Smart Custom Fields version $version (>= 5.0.1)"
  exit 0
fi

Sources

1. Patchstack advisory
2. Wordfence Intelligence record
3. WPScan record
4. WordPress plugin page
5. NVD entry
6. OpenCVE / CVE JSON mirror with CISA Vulnrichment
7. CISA weekly vulnerability bulletin
8. CISA KEV catalog