Missing Authorization vulnerability in osama

CVE-2025-22304 is a missing authorization flaw in the wp-stats-manager WordPress plugin, branded as *WP Visitor Statistics (Real Time Traffic)*. Public sources converge on vulnerable versions through 7.5, with a fix in 7.6; the weakness is a missing capability check that lets an authenticated low-privilege user, specifically Subscriber-level and above, trigger an action they should not be allowed to perform.

The vendor's MEDIUM 4.3 baseline is slightly high for enterprise patch triage. In the real world this requires an already-valid account on a site running a relatively niche plugin, and the published impact is only low integrity with no confidentiality or availability loss. That combination makes this a classic *post-auth web app hygiene* issue: worth fixing, but not something that should outrank unauthenticated RCE, auth bypass, or KEV-listed edge exposure.

Why this verdict

• Auth required cuts hard: the CVSS already says PR:L, and Patchstack explicitly states Subscriber access is required. That means the attacker must first win credentials or self-register where allowed, which is a major real-world narrowing from unauthenticated internet exploitation.
• Impact is narrow: the vector has C:N/I:L/A:N, so the published outcome is a limited unauthorized action, not code execution, admin creation, data theft, or service kill.
• Reachable population is smaller than the CVSS abstract suggests: only sites running this specific plugin are in scope, and only the subset exposing login or registration paths to attainable low-privilege users are realistically exploitable.

Why not higher?

There is no KEV listing, no cited in-the-wild activity, and no broadly visible public exploit kit in the sources reviewed. More importantly, exploitation begins *after* the attacker already has a valid account, which makes this a post-compromise or post-account-abuse problem rather than an initial foothold vulnerability.

Why not lower?

It still enables an unauthorized action across internet-reachable WordPress sites that use the plugin, and Subscriber accounts are not hypothetical on membership, community, or e-commerce deployments. Broken access control bugs also chain well with weak account governance, so this should not be ignored outright.

1. Disable public registration where unnecessary — If the site does not need self-service user creation, turn it off now. For a LOW verdict there is no formal mitigation SLA, but this is the fastest way to remove the most important exploit prerequisite while you move through normal patching.
2. Restrict Subscriber login paths — Put WordPress login, XML-RPC, and registration behind bot controls, SSO, MFA, or IP/geo restrictions where feasible. This reduces the chance that commodity credential stuffing can manufacture the low-privilege foothold the CVE needs.
3. Monitor plugin actions by low-privilege users — Enable or tune WordPress audit logging so actions touching wp-stats-manager from Subscriber accounts are visible. For a LOW finding, use this as a detective control during the backlog remediation window rather than treating it as an emergency response item.
4. Update the plugin — Move affected instances to 7.6 or later during normal plugin maintenance. Because this is LOW, fold it into backlog hygiene and complete patching within the long remediation window instead of burning an emergency change.

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

#!/usr/bin/env bash
# check-wp-stats-manager-cve-2025-22304.sh
# Detects whether WordPress plugin wp-stats-manager is vulnerable to CVE-2025-22304
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET="${1:-}"
PLUGIN_REL="wp-content/plugins/wp-stats-manager"
PLUGIN_DIR=""
VERSION=""
FIXED="7.6"

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

extract_version() {
  local base="$1"
  local readme="$base/readme.txt"
  local mainphp="$base/wp-stats-manager.php"

  if [ -f "$readme" ]; then
    VERSION=$(grep -E '^Stable tag:' "$readme" 2>/dev/null | head -n1 | sed -E 's/^Stable tag:[[:space:]]*//I' | tr -d '\r')
    if [ -n "$VERSION" ]; then
      return 0
    fi
  fi

  if [ -f "$mainphp" ]; then
    VERSION=$(grep -E '^[[:space:]]*Version:' "$mainphp" 2>/dev/null | head -n1 | sed -E 's/^[[:space:]]*Version:[[:space:]]*//I' | tr -d '\r')
    if [ -n "$VERSION" ]; then
      return 0
    fi
  fi

  return 1
}

if [ -z "$TARGET" ]; then
  echo "UNKNOWN - provide a WordPress root or plugin directory path"
  exit 2
fi

if [ -d "$TARGET/$PLUGIN_REL" ]; then
  PLUGIN_DIR="$TARGET/$PLUGIN_REL"
elif [ -d "$TARGET" ] && [ "$(basename "$TARGET")" = "wp-stats-manager" ]; then
  PLUGIN_DIR="$TARGET"
else
  echo "UNKNOWN - wp-stats-manager plugin directory not found under target path"
  exit 2
fi

if ! extract_version "$PLUGIN_DIR"; then
  echo "UNKNOWN - unable to determine plugin version from readme.txt or wp-stats-manager.php"
  exit 2
fi

# Normalize common placeholders
VERSION="$(echo "$VERSION" | awk '{print $1}')"

if verlte "$VERSION" "7.5"; then
  echo "VULNERABLE - wp-stats-manager version $VERSION (fixed in $FIXED)"
  exit 1
fi

if verlte "$FIXED" "$VERSION"; then
  echo "PATCHED - wp-stats-manager version $VERSION"
  exit 0
fi

echo "UNKNOWN - parsed version $VERSION could not be classified"
exit 2

Sources

1. NVD CVE-2025-22304
2. Patchstack advisory
3. WPScan vulnerability entry
4. WordPress.org plugin page
5. CISA KEV catalog
6. OpenCVE record
7. Rapid7 vulnerability database entry