Missing Authorization vulnerability in Hive Support Hive Support hive-support

CVE-2025-22298 is a missing authorization flaw in the WordPress hive-support plugin affecting versions through 1.1.6, fixed in 1.1.7. Public writeups agree on the important part: a logged-in attacker with Subscriber-level access or higher can reach at least one plugin function without the capability check that should gate it, letting that user perform an action they were not meant to perform.

The vendor/CNA MEDIUM 4.3 score is fair in a vacuum, but for enterprise patch triage it is too generous. The decisive friction is that this is post-auth on a tiny deployment footprint plugin, with no KEV listing, no public in-the-wild evidence located, and very low EPSS. That makes it a real defect, but not a fire drill.

Why this verdict

• Downgrade from vendor MEDIUM: this is authenticated remote with Subscriber+ privileges, which implies the attacker already has an account or prior compromise stage.
• Further downgrade for exposure: the official plugin page reports only 40+ active installations, so the addressable enterprise population is extremely small.
• Further downgrade for threat evidence: no KEV, no public exploitation evidence located, no public weaponized PoC located, and very low EPSS all argue against urgent adversary attention.

Why not higher?

There is no evidence this CVE is being exploited at scale, and the public impact is limited to low integrity rather than code execution or admin takeover. Just as important, requiring authenticated Subscriber+ access compounds real-world friction: this is a post-auth, narrow-population bug, not a broad internet-exposed initial-access flaw.

Why not lower?

It is still a genuine broken access control issue, not a theoretical hardening nit. On sites that allow user registration or already have lots of low-privilege accounts, a normal user being able to trigger a privileged plugin action is still unacceptable and deserves cleanup rather than outright dismissal.

1. Disable untrusted self-registration — If the site does not need open account creation, turn it off and prune stale Subscriber accounts. For a LOW finding there is no noisgate mitigation SLA, so handle this as backlog hygiene in the next normal WordPress administration cycle; the point is to remove the easiest path to satisfying the bug's biggest prerequisite.
2. Gate WordPress login behind stronger identity controls — Put wp-login.php and privileged site access behind SSO, MFA, bot protection, or IP restrictions where feasible. There is no noisgate mitigation SLA for LOW, but this is worth folding into your routine hardening baseline because it suppresses whole classes of authenticated plugin abuse, not just this CVE.
3. Turn on controlled plugin auto-updates — For low-install, non-core plugins, enable tested auto-update or at least owner-assigned update review so these long-tail WordPress bugs do not linger. With a LOW verdict there is no fixed mitigation deadline, so do it in the next maintenance window rather than as an emergency change.
4. Monitor low-privilege plugin activity — Add detections for unusual authenticated requests by Subscriber accounts, unexpected plugin setting changes, and sudden account creation spikes. Again, there is no noisgate mitigation SLA for LOW, but this provides useful telemetry for future WordPress plugin issues that also hide behind authentication.

Run this on the target WordPress host or on a mounted backup/container image with filesystem access. Invoke it as bash check-hive-support-cve-2025-22298.sh /var/www/html (or point it directly at the plugin directory); it only needs read access to the WordPress files under wp-content/plugins/hive-support.

#!/usr/bin/env bash
# check-hive-support-cve-2025-22298.sh
# Determine whether a WordPress installation is vulnerable to CVE-2025-22298
# Affected: Hive Support plugin <= 1.1.6
# Fixed:    1.1.7+
# Output:   VULNERABLE / PATCHED / UNKNOWN
# Exit:     1 vulnerable, 0 patched, 2 unknown

set -u

TARGET="${1:-}"
if [ -z "$TARGET" ]; then
  echo "UNKNOWN - usage: $0 <wordpress-root-or-hive-support-plugin-dir>"
  exit 2
fi

PLUGIN_DIR=""
if [ -d "$TARGET/wp-content/plugins/hive-support" ]; then
  PLUGIN_DIR="$TARGET/wp-content/plugins/hive-support"
elif [ -d "$TARGET" ] && [ "$(basename "$TARGET")" = "hive-support" ]; then
  PLUGIN_DIR="$TARGET"
else
  echo "UNKNOWN - hive-support plugin directory not found under: $TARGET"
  exit 2
fi

version=""

# Try readme first
if [ -f "$PLUGIN_DIR/readme.txt" ]; then
  version=$(awk -F': ' 'BEGIN{IGNORECASE=1} /^Stable tag:/ {gsub(/\r/,"",$2); print $2; exit}' "$PLUGIN_DIR/readme.txt")
fi

# Fallback: inspect plugin headers in PHP files
if [ -z "$version" ]; then
  while IFS= read -r -d '' phpfile; do
    candidate=$(awk -F': ' 'BEGIN{IGNORECASE=1} /^Version:/ {gsub(/\r/,"",$2); print $2; exit}' "$phpfile")
    if [ -n "$candidate" ]; then
      version="$candidate"
      break
    fi
  done < <(find "$PLUGIN_DIR" -maxdepth 2 -type f -name '*.php' -print0)
fi

# Normalize obvious non-version strings
if [ -z "$version" ] || [ "$version" = "trunk" ] || [ "$version" = "Development Version" ]; then
  echo "UNKNOWN - could not determine installed Hive Support version"
  exit 2
fi

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

if verlte "$version" "1.1.6"; then
  echo "VULNERABLE - Hive Support version $version (affected <= 1.1.6)"
  exit 1
else
  echo "PATCHED - Hive Support version $version (fixed in 1.1.7+)"
  exit 0
fi

Sources

1. NVD CVE-2025-22298
2. OpenCVE CNA record mirror
3. Patchstack advisory
4. Wordfence vulnerability entry
5. WPScan entry
6. WordPress.org plugin page
7. WordPress.org advanced view
8. CISA KEV catalog