Cross-Site Request Forgery

CVE-2025-22325 affects the WordPress plugin autocompleter by nchankov in versions up to and including 1.3.5.2. The flaw is a CSRF on a state-changing admin function with downstream stored XSS potential: if an attacker can get a logged-in WordPress administrator to visit a crafted page or click a malicious link, the browser can submit a forged request that changes plugin settings and stores attacker-controlled script content.

The vendor-style HIGH 7.1 label overstates real enterprise urgency. In practice this chain requires a logged-in admin session, user interaction, and the continued presence of an old plugin that public sources show as removed from the WordPress directory with only about 40 active installs. That is heavy friction, narrow population, and tiny reachable blast radius compared with true internet-facing unauthenticated bugs.

Why this verdict

• Baseline starts at vendor 7.1 HIGH, then drops hard because exploitation requires a logged-in admin to click or load attacker-controlled content. That is not unauthenticated remote compromise; it is a socially engineered browser-side action.
• Population is tiny. Wordfence shows roughly 40 active installs, which is microscopic compared with vulnerabilities that matter at fleet scale.
• This prerequisite implies prior opportunity, not initial access. The attacker either already has a path to influence an administrator or must win a phishing/social-engineering step first, and modern email security/browser controls should catch a meaningful share of those attempts.
• Blast radius is local to one WordPress site. There is no evidence this becomes broad infrastructure takeover absent further site-specific chaining.
• No KEV listing, no public campaign evidence, and a very low EPSS all point the same way: low probability, low prioritization pressure.

Why not higher?

It is not higher because this is not a clean internet-exposed pre-auth exploit. The attacker must line up a rare plugin, an authenticated admin session, and successful user interaction before any impact occurs. That is multiple compounding friction points, and each one should drag the score down.

Why not lower?

It is not IGNORE because, if the plugin is present, the weakness is real and there is no public patch. A successful hit can still land stored JavaScript in a WordPress site and create credential theft or admin-action abuse. That deserves cleanup, just not panic.

1. Remove the plugin — If autocompleter is installed anywhere, remove or replace it because public sources show no official fix. For a LOW verdict there is no formal noisgate mitigation SLA, but this is still sensible backlog hygiene because leaving an unpatched, removed plugin in production buys you nothing.
2. Restrict admin exposure — Put wp-admin behind VPN, IP allowlists, or SSO access controls where possible. This reduces the chance that a phished or casually browsing administrator can be used as the CSRF trigger.
3. Harden browser-side script execution — Use a sane CSP and security headers to reduce stored-XSS reliability if a payload lands. This is not a full fix, but it meaningfully cuts follow-on abuse on public-facing sites.
4. Watch for suspicious settings changes — Monitor WordPress admin actions, plugin-setting updates, and unexpected JavaScript in stored options/content. Do this during normal content-integrity review cycles; there is no urgent mitigation deadline for a LOW reassessment.

Run this on the target WordPress host or on a mounted web root from an auditor workstation. Invoke it as bash verify-cve-2025-22325.sh /var/www/html and use an account that can read the WordPress plugin directory; root is not required unless file permissions are locked down.

#!/usr/bin/env bash
# verify-cve-2025-22325.sh
# Detects whether WordPress plugin 'autocompleter' is installed and vulnerable to CVE-2025-22325.
# Usage: bash verify-cve-2025-22325.sh /path/to/wordpress
# Exit codes:
#   0 = PATCHED / not present
#   1 = VULNERABLE
#   2 = UNKNOWN / inspection error

set -u

TARGET_ROOT="${1:-}"
if [[ -z "$TARGET_ROOT" ]]; then
  echo "UNKNOWN: missing WordPress root path argument"
  exit 2
fi

PLUGIN_DIR="$TARGET_ROOT/wp-content/plugins/autocompleter"
if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "PATCHED: plugin 'autocompleter' not present"
  exit 0
fi

find_main_file() {
  local dir="$1"
  local f
  for f in "$dir"/*.php; do
    [[ -f "$f" ]] || continue
    if grep -qiE '^\s*Plugin Name\s*:' "$f"; then
      echo "$f"
      return 0
    fi
  done
  return 1
}

MAIN_FILE="$(find_main_file "$PLUGIN_DIR")"
if [[ -z "${MAIN_FILE:-}" || ! -f "$MAIN_FILE" ]]; then
  echo "UNKNOWN: plugin directory exists but main plugin file could not be identified"
  exit 2
fi

VERSION_LINE="$(grep -iE '^\s*Version\s*:' "$MAIN_FILE" | head -n1 || true)"
VERSION="$(echo "$VERSION_LINE" | sed -E 's/^\s*Version\s*:\s*//I' | tr -d '\r' | xargs)"

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN: could not parse plugin version from $MAIN_FILE"
  exit 2
fi

# Returns 0 if $1 <= $2 using sort -V semantics.
version_le() {
  local a="$1" b="$2"
  [[ "$a" == "$b" ]] && return 0
  local first
  first="$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)"
  [[ "$first" == "$a" ]]
}

AFFECTED_MAX="1.3.5.2"

if version_le "$VERSION" "$AFFECTED_MAX"; then
  echo "VULNERABLE: autocompleter version $VERSION found at $PLUGIN_DIR (affected: <= $AFFECTED_MAX)"
  exit 1
else
  echo "PATCHED: autocompleter version $VERSION is newer than $AFFECTED_MAX"
  exit 0
fi

Sources

1. Wordfence vulnerability entry for CVE-2025-22325
2. Wordfence plugin metadata for Autocompleter
3. Patchstack advisory for Autocompleter <= 1.3.5.2
4. CISA Known Exploited Vulnerabilities catalog
5. FIRST EPSS API documentation
6. FIRST EPSS overview
7. Wordfence CVE database overview showing removed status and active installs