Improper Neutralization of Input During Web Page Generation

CVE-2025-22293 is a stored/DOM-style XSS issue in the WordPress gutentor plugin. Current public tracking converges on affected versions <= 3.4.3, with 3.4.4 listed as the fix; earlier CVE metadata originally said <= 3.4.0, then NVD shows that record was later updated to <= 3.4.3. Exploitation requires an authenticated WordPress user at Contributor+ level to place attacker-controlled content into Gutentor-managed page elements so script runs when another user views the injected page.

The vendor/CNA-style 6.5 MEDIUM score is defensible in a vacuum, but it overstates enterprise urgency. The decisive friction is attacker position: this is not unauthenticated internet exploitation, it is post-login abuse of a specific WordPress role on a specific plugin, with no KEV entry, very low EPSS, and no strong evidence of active campaigns. For most enterprises, the reachable population is the subset of sites that both run Gutentor and allow low-privilege content authors.

Why this verdict

• Downgrade for attacker position: exploitation starts at authenticated Contributor+, which already implies prior credential compromise, insider access, or open author registration.
• Downgrade for exposure fraction: only organizations running WordPress, using Gutentor, and permitting low-privilege content authors are meaningfully exposed; that is a narrow slice of a 10,000-host enterprise.
• Downgrade for threat evidence: no KEV listing, very low EPSS, and no solid public evidence of active campaign use in reviewed sources.

Why not higher?

This is not unauthenticated RCE, not a perimeter bypass, and not a one-packet internet-wide wormable issue. The chain depends on a low-privilege CMS foothold plus a victim viewing the poisoned content, which compounds real-world friction fast.

Why not lower?

It is still a real stored XSS bug in a plugin with 30,000+ installs, and Contributor is not an especially rare role on publishing-heavy sites. If an attacker can land on a multi-author site, stored XSS can absolutely become admin-session theft or site takeover, so dismissing it as IGNORE would be sloppy.

1. Inventory Gutentor immediately — Identify every WordPress instance running gutentor and pull exact plugin versions. Because this is a LOW verdict, there is no mitigation SLA; do this in normal backlog hygiene and use it to separate <= 3.4.3 from patched estates.
2. Clamp down Contributor access — Review who actually has Contributor/Author roles, disable public registration where unused, and remove dormant accounts. This directly attacks the exploit precondition and should be done as routine identity hygiene since there is no formal mitigation SLA for LOW findings.
3. Enforce MFA and SSO for WordPress admins and authors — MFA will not fix the vulnerable code, but it materially reduces the easiest path to exploitation: stolen content-author credentials. Roll this out on vulnerable sites during the normal maintenance cycle.
4. Add a restrictive CSP where practical — A sane Content Security Policy can reduce exploit reliability and token exfil paths for stored XSS, especially on admin and editor surfaces. Deploy as defense-in-depth in the same maintenance window if your theme/plugin stack tolerates it.
5. Patch to 3.4.4 or later — Move vulnerable instances off <= 3.4.3 to the vendor-fixed release or newer. For a LOW verdict this is backlog hygiene, not an emergency, but it should still land on your standard plugin update cadence.

Run this on the target WordPress host or inside the container/VM that serves the site. Invoke it as bash check_cve_2025_22293.sh /var/www/html and use an account with read access to the WordPress files; root is not required unless your web root is locked down.

#!/usr/bin/env bash
# check_cve_2025_22293.sh
# Detect whether the WordPress Gutentor plugin version is vulnerable to CVE-2025-22293.
# Usage: bash check_cve_2025_22293.sh /path/to/wordpress
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

WP_ROOT="${1:-}"
PLUGIN_DIR=""
VERSION=""

if [ -z "$WP_ROOT" ]; then
  echo "UNKNOWN: missing WordPress root path"
  exit 2
fi

PLUGIN_DIR="$WP_ROOT/wp-content/plugins/gutentor"

if [ ! -d "$PLUGIN_DIR" ]; then
  echo "UNKNOWN: Gutentor plugin directory not found at $PLUGIN_DIR"
  exit 2
fi

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

# Try the main plugin file first, then readme.txt
for candidate in \
  "$PLUGIN_DIR/gutentor.php" \
  "$PLUGIN_DIR/readme.txt"; do
  VERSION="$(extract_version "$candidate")"
  if [ -n "$VERSION" ]; then
    break
  fi
done

if [ -z "$VERSION" ] && command -v wp >/dev/null 2>&1; then
  VERSION="$(wp plugin get gutentor --field=version --path="$WP_ROOT" 2>/dev/null | tr -d '\r')"
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN: could not determine Gutentor version"
  exit 2
fi

# Normalize version string to first token that looks like digits.digits
VERSION="$(echo "$VERSION" | sed -E 's/^([^0-9]*)([0-9]+(\.[0-9]+)+).*/\2/')"

if [ -z "$VERSION" ]; then
  echo "UNKNOWN: parsed version is empty"
  exit 2
fi

# version <= 3.4.3 is vulnerable; >= 3.4.4 is patched
if [ "$(printf '%s\n' "$VERSION" "3.4.3" | sort -V | head -n1)" = "$VERSION" ] && [ "$VERSION" != "3.4.4" ]; then
  if [ "$VERSION" = "3.4.3" ] || [ "$(printf '%s\n' "$VERSION" "3.4.3" | sort -V | tail -n1)" = "3.4.3" ]; then
    echo "VULNERABLE: Gutentor version $VERSION (<= 3.4.3)"
    exit 1
  fi
fi

if [ "$(printf '%s\n' "$VERSION" "3.4.4" | sort -V | head -n1)" = "3.4.4" ] || [ "$VERSION" = "3.4.4" ]; then
  echo "PATCHED: Gutentor version $VERSION (>= 3.4.4)"
  exit 0
fi

# Fallback logic
if [ "$(printf '%s\n' "$VERSION" "3.4.3" | sort -V | head -n1)" = "$VERSION" ]; then
  echo "VULNERABLE: Gutentor version $VERSION (<= 3.4.3)"
  exit 1
else
  echo "PATCHED: Gutentor version $VERSION (> 3.4.3)"
  exit 0
fi

Sources

1. WordPress.org plugin page and changelog for Gutentor
2. Wordfence vulnerability entry for CVE-2025-22293
3. Patchstack advisory for CVE-2025-22293
4. NVD entry and change history for CVE-2025-22293
5. CISA Known Exploited Vulnerabilities Catalog
6. OpenCVE record reflecting CNA metadata for CVE-2025-22293
7. WordPress.org support discussion on CVE-2025-22293
8. FIRST EPSS documentation