Improper Neutralization of Input During Web Page Generation

CVE-2025-22261 is a stored XSS in the WordPress WP FullCalendar plugin affecting versions through 1.5 and fixed in 1.6. The practical abuse case described by WordPress ecosystem sources is that an attacker with Contributor+ access can place JavaScript into content rendered by the plugin, and that script runs later in the browser of whoever views the affected page in the site's origin.

The vendor's MEDIUM 6.5 score is technically defensible in a vacuum, but it overstates enterprise patch urgency. The decisive friction is that exploitation is already post-auth: the attacker needs a valid low-privilege WordPress account and then still needs a victim to render the poisoned page. That makes this a workflow abuse problem inside a niche plugin population, not a broad unauthenticated internet takeover.

Why this verdict

• Post-auth prerequisite cuts hard against urgency: starting from the vendor's 6.5 baseline, this flaw needs Contributor+ access, which implies prior compromise, credential theft, or an intentionally open publishing workflow before the XSS even starts.
• A victim must still render the poisoned page: this is stored XSS with UI:R, so the attacker does not get instant server-side impact or unauthenticated one-shot exploitation.
• Reachable population is small: only sites running the niche WP FullCalendar plugin on <= 1.5 are in scope, and public install counts are in the 8k-10k range, not hundreds of thousands or millions.
• Threat signal is weak: there is no KEV listing, no strong public PoC signal, and EPSS is near the floor, so there is no evidence the market is weaponizing this at scale.

Why not higher?

This is not higher because there is no unauthenticated path, no server-side code execution, and no broad internet edge exposure. The chain assumes a prior low-privilege foothold plus a successful content-render event, which is exactly the kind of compounding friction that should drag severity down in enterprise patch triage.

Why not lower?

It is not IGNORE because stored XSS in a CMS can still cross privilege boundaries when an editor or admin views the payload. On the affected site, the bug can become a browser-side stepping stone to session abuse, nonce theft, or malicious content changes, so it deserves inventorying and cleanup rather than dismissal.

1. Restrict Contributor publishing paths — Limit who can create or edit content that reaches WP FullCalendar rendering, especially shortcode-driven pages. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is the fastest way to remove the exploitable path without waiting on a plugin update.
2. Enforce MFA for WordPress authors and contributors — This bug is only useful after the attacker gets a valid low-privilege account, so shrinking credential abuse matters more than perimeter filtering. For LOW, there is no SLA (treat as backlog hygiene); roll into your normal identity hardening program.
3. Disable or remove the plugin where unused — If the calendar feature is not business-critical, removing wp-fullcalendar erases both the vulnerable code path and future plugin maintenance burden. For LOW, there is no SLA (treat as backlog hygiene); prune it during your next WordPress maintenance pass.
4. Review recent contributor-created content — Hunt for suspicious script fragments, odd shortcode attributes, unexpected HTML, and anomalous post revisions tied to low-privilege users. For LOW, there is no SLA (treat as backlog hygiene), but this is the best validation step if you suspect account abuse.

Run this on the target WordPress host or a mounted backup of the site content. Invoke it as bash check-wp-fullcalendar-cve-2025-22261.sh /var/www/html and provide a WordPress root path; read-only access is enough, no root required unless filesystem permissions demand it.

#!/usr/bin/env bash
# check-wp-fullcalendar-cve-2025-22261.sh
# Purpose: Determine whether a local WordPress installation is vulnerable to CVE-2025-22261
# Affected: WP FullCalendar <= 1.5
# Fixed:    WP FullCalendar >= 1.6
# Output:   VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

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

PLUGIN_DIR="$WP_ROOT/wp-content/plugins/wp-fullcalendar"
README_FILE="$PLUGIN_DIR/readme.txt"
MAIN_FILE="$PLUGIN_DIR/wp-fullcalendar.php"

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

version=""

# Try plugin readme first (Stable tag)
if [[ -f "$README_FILE" ]]; then
  version=$(awk -F': *' 'BEGIN{IGNORECASE=1} /^Stable tag:/ {print $2; exit}' "$README_FILE" | tr -d '\r')
fi

# Fall back to plugin header version
if [[ -z "$version" && -f "$MAIN_FILE" ]]; then
  version=$(awk -F': *' 'BEGIN{IGNORECASE=1} /^Version:/ {print $2; exit}' "$MAIN_FILE" | tr -d '\r')
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN - could not determine wp-fullcalendar version from readme or plugin header"
  exit 2
fi

normalize_version() {
  echo "$1" | sed 's/^[[:space:]]*//; s/[[:space:]]*$//'
}

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

vergte() {
  # returns success if $1 >= $2
  [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" == "$1" ]]
}

version=$(normalize_version "$version")

affected_max="1.5"
fixed_min="1.6"

if verlte "$version" "$affected_max"; then
  echo "VULNERABLE - wp-fullcalendar version $version (affected <= $affected_max)"
  exit 1
fi

if vergte "$version" "$fixed_min"; then
  echo "PATCHED - wp-fullcalendar version $version (fixed >= $fixed_min)"
  exit 0
fi

echo "UNKNOWN - parsed version '$version' but could not classify confidently"
exit 2

Sources

1. WordPress.org plugin page and changelog
2. OpenCVE CNA record for CVE-2025-22261
3. Wordfence vulnerability entry
4. WPScan plugin page
5. Rapid7 vulnerability database entry
6. Wiz vulnerability database entry
7. CISA Known Exploited Vulnerabilities catalog
8. FIRST EPSS API documentation