The Boost plugin for WordPress is vulnerable to PHP Object Injection in versions up to

CVE-2026-7637 is an unauthenticated PHP object injection in the WordPress Boost plugin affecting versions <= 2.0.3, triggered by unsafe deserialization of the STYXKEY-BOOST_USER_LOCATION cookie. Any public-facing WordPress site running the plugin can be reached remotely, and the bug sits on a low-friction input path: an attacker just sends a crafted cookie and lets PHP rebuild attacker-controlled objects.

The vendor-style 9.8/CRITICAL score overstates fleet-wide reality because the vulnerable plugin does not include its own POP chain. Per Wordfence, impact only materializes if some *other* installed plugin or theme supplies usable gadgets. That is still dangerous in plugin-heavy WordPress estates, but it is not the same thing as standalone pre-auth RCE; the missing gadget chain is the decisive friction point that pulls this down to HIGH instead of leaving it at CRITICAL.

Why this verdict

• Downgrade from 9.8 because a second prerequisite exists: the attacker needs a usable POP chain from another installed plugin or theme, which is a hard real-world dependency not captured in the base CVSS.
• Still HIGH because attacker position is excellent: this is unauthenticated, remote, internet-reachable input via a cookie on public WordPress sites, so initial access friction is otherwise very low.
• Blast radius can still be ugly on the right site: when a gadget chain exists, the attacker may reach file read, file deletion, or code execution in the web context, which is enough for WordPress takeover and secret theft.

Why not higher?

It is not CRITICAL because the exploit chain is incomplete in the vulnerable product itself. A vulnerability that needs public reachability plus a separate gadget-bearing plugin/theme is materially less reliable than direct pre-auth RCE, and that extra dependency should count heavily in enterprise prioritization.

Why not lower?

It is not MEDIUM because the first half of the chain is extremely easy: remote, unauthenticated, and cookie-based on a public web app. In WordPress environments with many plugins and themes, the odds of a usable gadget chain are not theoretical, so the residual risk remains too high to relegate to routine backlog work.

1. Upgrade to 2.0.4+ — Apply the vendor fix everywhere the Boost plugin is present. For a HIGH verdict, complete this within 30 days as the practical mitigation target and no later than the patch deadline called out in bottom_line.
2. Block serialized cookie payloads — Add WAF or reverse-proxy rules to inspect the STYXKEY-BOOST_USER_LOCATION cookie for PHP serialization markers and oversized/encoded payloads. This is a compensating control, not a guaranteed fix, and should be deployed within 30 days where immediate plugin updates are operationally hard.
3. Prune unused plugins and themes — Reduce gadget-chain surface by removing inactive or abandoned plugins/themes, especially on marketing sites with plugin sprawl. This matters here because the exploit becomes dangerous only when another component contributes the POP chain; start cleanup within 30 days.
4. Restrict public exposure where possible — If some sites using this plugin do not need broad internet reach, gate them behind VPN, SSO proxy, IP allowlists, or maintenance mode while you patch. That cuts off the unauthenticated remote entry point and should be implemented within 30 days for exceptions.
5. Hunt for post-exploitation artifacts — Review for unexpected plugin/theme file changes, suspicious PHP drops, webshells, and access to wp-config.php. This should begin immediately on high-value or plugin-dense WordPress estates because compromise, if it lands, usually becomes a content-management and credential-theft problem fast.

Run this on the target WordPress host as a user that can read the WordPress files; root is not required unless file permissions are locked down. Invoke it with the plugin directory path, for example: bash check_boost_cve_2026_7637.sh /var/www/html/wp-content/plugins/boost.

#!/usr/bin/env bash
# check_boost_cve_2026_7637.sh
# Detects whether the WordPress Boost plugin version is vulnerable to CVE-2026-7637.
# Usage: bash check_boost_cve_2026_7637.sh /path/to/wp-content/plugins/boost
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

TARGET_PATH="${1:-}"

if [[ -z "$TARGET_PATH" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/wp-content/plugins/boost"
  exit 2
fi

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

version=""

# Try common plugin entrypoint files first.
for f in "$TARGET_PATH/boost.php" "$TARGET_PATH/index.php"; do
  if [[ -f "$f" ]]; then
    v=$(grep -Eim1 '^[[:space:]]*Version:[[:space:]]*[0-9][0-9A-Za-z._-]*' "$f" | sed -E 's/^[[:space:]]*Version:[[:space:]]*//I' | tr -d '\r')
    if [[ -n "$v" ]]; then
      version="$v"
      break
    fi
  fi
done

# Fallback to readme.txt stable tag.
if [[ -z "$version" && -f "$TARGET_PATH/readme.txt" ]]; then
  v=$(grep -Eim1 '^[[:space:]]*Stable tag:[[:space:]]*[0-9][0-9A-Za-z._-]*' "$TARGET_PATH/readme.txt" | sed -E 's/^[[:space:]]*Stable tag:[[:space:]]*//I' | tr -d '\r')
  if [[ -n "$v" ]]; then
    version="$v"
  fi
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN - unable to determine installed Boost plugin version"
  exit 2
fi

# Normalize a leading 'v'
version="${version#v}"

# Compare using sort -V; assumes GNU coreutils available on most Linux hosts.
if [[ "$(printf '%s\n' "$version" "2.0.3" | sort -V | head -n1)" == "$version" ]] && [[ "$version" != "2.0.4" ]] && [[ "$version" != "2.0.5" ]] && [[ "$version" != "2.0.6" ]]; then
  # If version <= 2.0.3
  if [[ "$version" == "$(printf '%s\n' "$version" "2.0.3" | sort -V | head -n1)" ]]; then
    echo "VULNERABLE - Boost version $version is <= 2.0.3"
    exit 1
  fi
fi

# Simpler direct check after normalization
if [[ "$version" == "$(printf '%s\n' "$version" "2.0.3" | sort -V | head -n1)" && "$version" != "2.0.3" ]] || [[ "$version" == "2.0.3" ]] || [[ "$version" == "2.0.2" ]] || [[ "$version" == "2.0.1" ]] || [[ "$version" == "2.0.0" ]]; then
  echo "VULNERABLE - Boost version $version is <= 2.0.3"
  exit 1
fi

if [[ "$version" == "$(printf '%s\n' "2.0.4" "$version" | sort -V | head -n1)" ]]; then
  echo "PATCHED - Boost version $version is >= 2.0.4"
  exit 0
fi

echo "UNKNOWN - parsed version '$version' but comparison was inconclusive"
exit 2

Sources

1. NVD CVE-2026-7637
2. Wordfence specific advisory
3. Patchstack advisory
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS overview
6. FIRST EPSS API documentation
7. PixelYourSite Boost plugin page
8. SentinelOne CVE summary