Cross-Site Request Forgery

CVE-2025-22300 is a CSRF flaw in the WordPress plugin PixelYourSite – Your smart PIXEL (TAG) Manager. Affected versions are <= 10.0.1.2, and the fix landed in 10.0.2. Third-party analysis attributes the issue to missing or incorrect nonce validation in the plugin's init() path, which means an attacker can craft a request that changes plugin settings if a privileged WordPress user submits it while authenticated.

The vendor's MEDIUM 5.4 score is defensible in a vacuum, but for enterprise patch triage it overstates urgency. This is not unauthenticated internet-to-RCE; it is user-interaction-required admin-session riding against a single plugin's settings surface. Broad install base matters, but the practical exploit chain still depends on luring a logged-in admin and only yields configuration tampering, so this drops into LOW for most 10,000-host programs.

Why this verdict

• Downgrade for attacker position: despite PR:N in CVSS, the real-world chain still needs an already-authenticated admin session, which implies the attacker must first reach a privileged user rather than the server itself.
• Downgrade for population actually reachable by the exploit step: 500k+ installs is broad, but only the subset where admins can be lured while logged in is exploitable; that is a much narrower operational population than the install count suggests.
• Downgrade for tool friction: modern email security, browser isolation, short-lived admin sessions, and separate admin workstations often break the lure step before the forged request lands.
• Keep above IGNORE because blast radius is still real: Pixel/analytics settings can affect tracking integrity, privacy posture, and business reporting, so this is not a fake bug or a harmless edge case.

Why not higher?

There is no evidence here of unauthenticated code execution, privilege escalation on the server, or a direct internet-reachable edge exploit. The exploit chain is fragile because it depends on user interaction by a privileged admin and only changes plugin settings, so this does not belong in MEDIUM-or-higher Monday-morning fire-drill territory.

Why not lower?

This is still a legitimate, patched vulnerability in a plugin with a very large deployment base. If the writable options are abused, you can lose integrity in analytics and compliance-relevant tracking behavior, so documenting and eventually fixing it is warranted rather than dismissing it outright.

1. Restrict admin browsing — Have WordPress administrators perform plugin administration only from dedicated admin profiles or workstations, and avoid casual browsing while logged in. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and fold the control into normal admin-hardening practice.
2. Turn on WordPress audit logging — Log plugin-option changes and admin POST activity so forged settings changes are visible after the fact. For LOW, there is no mitigation SLA; add this in the next normal monitoring improvement cycle if not already present.
3. Use security plugins with admin-change monitoring — WordPress-focused security tooling can alert on plugin setting changes, which is more useful here than generic perimeter blocking. For LOW, there is no mitigation SLA; deploy as part of regular platform hygiene.
4. Shorten admin session exposure — Reduce persistent logged-in admin sessions and require reauthentication for privileged work where feasible. That directly attacks the CSRF precondition by shrinking the window in which a lure can reuse the victim's cookies.

Run this on the WordPress host or inside the container/VM that serves the site. Invoke it as bash check-pixelyoursite-cve-2025-22300.sh /var/www/html or point it directly at the plugin directory; it needs read access to the WordPress files only, not root.

#!/usr/bin/env bash
# check-pixelyoursite-cve-2025-22300.sh
# Detect whether the installed PixelYourSite plugin version is affected by CVE-2025-22300.
# Usage:
#   bash check-pixelyoursite-cve-2025-22300.sh /var/www/html
#   bash check-pixelyoursite-cve-2025-22300.sh /var/www/html/wp-content/plugins/pixelyoursite
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

TARGET="${1:-}"
if [ -z "$TARGET" ]; then
  echo "UNKNOWN - provide WordPress root or plugin directory path"
  exit 2
fi

PLUGIN_DIR=""
MAIN_FILE=""

if [ -d "$TARGET/wp-content/plugins/pixelyoursite" ]; then
  PLUGIN_DIR="$TARGET/wp-content/plugins/pixelyoursite"
elif [ -d "$TARGET" ] && [ -f "$TARGET/pixelyoursite.php" ]; then
  PLUGIN_DIR="$TARGET"
else
  echo "UNKNOWN - PixelYourSite plugin directory not found at target path"
  exit 2
fi

MAIN_FILE="$PLUGIN_DIR/pixelyoursite.php"
if [ ! -r "$MAIN_FILE" ]; then
  echo "UNKNOWN - cannot read $MAIN_FILE"
  exit 2
fi

VERSION=$(awk -F': ' 'BEGIN{IGNORECASE=1} /^Version:[[:space:]]*/ {gsub(/\r/,"",$2); print $2; exit}' "$MAIN_FILE")
if [ -z "$VERSION" ]; then
  VERSION=$(grep -Eoi "Version:[[:space:]]*[0-9]+(\.[0-9]+)+" "$MAIN_FILE" | head -n1 | sed -E 's/Version:[[:space:]]*//I')
fi

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

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

if verlte "$VERSION" "10.0.1.2"; then
  echo "VULNERABLE - PixelYourSite version $VERSION (affected: <= 10.0.1.2, fixed: 10.0.2+)"
  exit 1
fi

if verlte "10.0.2" "$VERSION"; then
  echo "PATCHED - PixelYourSite version $VERSION"
  exit 0
fi

echo "UNKNOWN - detected version $VERSION but comparison was inconclusive"
exit 2

Sources

1. NVD CVE-2025-22300
2. Patchstack advisory for PixelYourSite <= 10.0.1.2
3. Wordfence vulnerability record
4. WordPress.org plugin page and changelog
5. OpenCVE record with CNA and CISA ADP metadata
6. Rapid7 vulnerability database entry
7. CISA Known Exploited Vulnerabilities catalog
8. FIRST EPSS API documentation