Improper Neutralization of Input During Web Page Generation

CVE-2025-22323 is a stored XSS in the WordPress plugin Image Hover Effects for Elementor (image-hover-effects-elementor-addon). Public sources disagree slightly on the upper bound: Wordfence/WPScan track it as affecting <= 1.0.2.3, while Patchstack and the current NVD record say <= 1.0.2.4. The practical attack is the same either way: a user with Contributor-level or higher access can save malicious content that later executes in another user's browser when the poisoned page is viewed.

The vendor's MEDIUM 6.5 is technically defensible in a lab, but too high for enterprise patch triage. The decisive reality is attacker position: this is not unauthenticated internet RCE, it is post-auth CMS abuse in a plugin with only 50+ active installs and no credible exploitation signal. That combination pushes this into LOW for most defenders, with attention only if you actually run the plugin on multi-author WordPress sites.

Why this verdict

• Post-auth requirement cuts hard: the vendor's 6.5 assumes network reachability, but PR:L means the attacker already has WordPress access. In enterprise terms that implies prior compromise, delegated author access, or a weak IAM model — all of which materially narrow exposure.
• UI:R is real friction: this is stored XSS, but someone still has to view the poisoned content for it to matter. If the payload never reaches an admin/editor eyeball, impact stays limited and often noisy rather than catastrophic.
• Tiny install base drops the fleet priority: the plugin directory shows only 50+ active installs. That is nowhere near the exposure density that justifies treating a medium WordPress XSS like a broad emergency.

Why not higher?

There is no evidence of active exploitation, no public PoC traction, no KEV listing, and no unauthenticated path. This is also site-local browser impact, not server-side RCE or a fleet-spreading primitive. Even on an affected host, multiple real-world prerequisites must line up before the impact becomes meaningful.

Why not lower?

Stored XSS in a CMS is still operationally relevant because it can target higher-privileged admins or editors who review content. If your WordPress sites use external contributors, agencies, marketing contractors, or shared authoring workflows, this can become a practical privilege-pivot on that specific site.

1. Restrict Contributor access — Remove or tightly scope Contributor+ roles on sites running this plugin, especially for contractor or agency accounts. For a LOW verdict there is no SLA beyond backlog hygiene, but do this in the next routine IAM review because it directly removes the exploit prerequisite.
2. Disable or remove the plugin where unused — If the widget is not business-critical, uninstalling or disabling it collapses the attack surface entirely. For LOW, handle during normal maintenance rather than breaking change windows.
3. Review recently edited content by low-privileged authors — Inspect drafts, pages, and plugin-rendered content created by Contributors or Editors for suspicious HTML/JS payloads. This is backlog-hygiene work for LOW, but it is the fastest way to catch abuse if you suspect a compromised author account.
4. Enforce MFA and SSO on WordPress author accounts — MFA will not neutralize the XSS itself, but it raises the cost of obtaining the required Contributor account. For LOW, fold this into your standing WordPress hardening program rather than emergency change control.
5. Consider a strict CSP on admin and front-end pages — A well-tuned Content Security Policy can reduce the reliability of many XSS payloads, especially inline script execution. This is not a same-day mitigation for most WordPress stacks, but it is a high-value hardening move during regular backlog work.

Run this on the target WordPress host with read access to the web root. Invoke it as bash check_cve_2025_22323.sh /var/www/html (adjust the WordPress path); root is not required unless your web files are unreadable to the current user.

#!/usr/bin/env bash
# check_cve_2025_22323.sh
# Determine whether a WordPress instance is affected by CVE-2025-22323
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

WP_ROOT="${1:-}"
PLUGIN_SLUG="image-hover-effects-elementor-addon"
AFFECTED_MAX="1.0.2.4"

if [[ -z "$WP_ROOT" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/wordpress"
  exit 2
fi

PLUGIN_DIR="$WP_ROOT/wp-content/plugins/$PLUGIN_SLUG"
if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "UNKNOWN - plugin directory not found: $PLUGIN_DIR"
  exit 2
fi

find_main_file() {
  local candidates=(
    "$PLUGIN_DIR/${PLUGIN_SLUG}.php"
    "$PLUGIN_DIR/image-hover-effects-elementor-addon.php"
    "$PLUGIN_DIR/plugin.php"
  )

  for f in "${candidates[@]}"; do
    if [[ -f "$f" ]]; then
      echo "$f"
      return 0
    fi
  done

  local first_php
  first_php=$(find "$PLUGIN_DIR" -maxdepth 1 -type f -name '*.php' | head -n 1)
  if [[ -n "$first_php" ]]; then
    echo "$first_php"
    return 0
  fi

  return 1
}

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

MAIN_FILE=$(find_main_file) || {
  echo "UNKNOWN - could not locate plugin main PHP file under $PLUGIN_DIR"
  exit 2
}

VERSION=$(grep -Eim1 '^\s*Version:\s*' "$MAIN_FILE" | sed -E 's/^\s*Version:\s*//I' | tr -d '\r')

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

if version_le "$VERSION" "$AFFECTED_MAX"; then
  echo "VULNERABLE - $PLUGIN_SLUG version $VERSION is within published affected range <= $AFFECTED_MAX"
  exit 1
else
  echo "PATCHED - $PLUGIN_SLUG version $VERSION is outside the published affected range <= $AFFECTED_MAX"
  exit 0
fi

Sources

1. NVD CVE-2025-22323
2. Patchstack advisory for CVE-2025-22323
3. Wordfence advisory for CVE-2025-22323
4. WPScan entry for CVE-2025-22323
5. WordPress plugin directory: Image Hover Effects for Elementor
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS model documentation