The WishList Member plugin for WordPress is vulnerable to Missing Authorization leading to Sensitive…

CVE-2026-6895 affects the commercial wishlist-member-x WordPress plugin in versions up to and including 3.30.1 and is fixed in 3.31.0. A low-privileged authenticated user can call the vulnerable export_settings path, receive the WishList Member REST API key in an AJAX response, then use that key to create a membership level mapped to the WordPress administrator role and mint a new admin account.

The vendor's 8.8/HIGH score is technically fair in a lab because the end state is full site takeover, but it overstates broad enterprise urgency. The chain starts with PR:L, which in the real world means either open self-registration, cheap paid signup, or an already-compromised subscriber account; that is a real friction point, and the plugin's overall population is small enough that this is not a mass-internet emergency absent exploitation evidence.

Why this verdict

• Start from 8.8, then cut for attacker position: vendor scoring assumes full-value internet reach, but PR:L means the attacker needs a subscriber account before anything interesting happens.
• Exposure population is narrow: WishList Member is a niche commercial membership plugin, not a mass-installed core dependency. Even the higher vendor marketing number reflects cumulative activations, not current exposed fleet.
• The prerequisite often implies prior compromise or business-process abuse: if registration is closed, paid, approved, or invite-only, exploitation becomes post-initial-access rather than first-hop internet exploitation.
• No exploitation evidence is doing more work than the CVSS does: no KEV, no public campaign reporting, and a very low user-supplied EPSS all argue against emergency fleet-wide treatment.
• Impact is still real: once a subscriber can hit the vulnerable action, the chain leads to admin creation and full WordPress takeover, so this is not backlog trash.

Why not higher?

This is not a clean unauthenticated remote takeover. The exploit chain depends on a low-privileged account and a plugin that is comparatively narrow in deployment, which compounds the reachable-population problem. In enterprise triage terms, that is a substantial downgrade from the vendor's lab score.

Why not lower?

The post-auth impact is complete site compromise, not just data leakage or a cosmetic role bug. On any affected site with open or easy self-registration, the friction collapses fast and a low-skill attacker can plausibly buy or create their way to admin.

1. Disable public self-registration on affected sites — If the site does not strictly need anonymous signup, close the cheapest path into PR:L. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do this early on any internet-facing membership site because it materially changes exploitability.
2. Regenerate the WishList Member API key — The exploit chain turns on disclosure of the plugin's API credential, so rotate it anywhere exposure is suspected and invalidate any copied key. There is no mitigation SLA — go straight to the 365-day remediation window, but key rotation should be bundled with patch validation on exposed sites.
3. Monitor and, if needed, block suspicious WishList AJAX and API paths — Add temporary WAF or reverse-proxy controls around suspicious authenticated requests to wp-admin/admin-ajax.php for WishList actions and unusual traffic to ?/wlmapi/2.0/. There is no mitigation SLA — go straight to the 365-day remediation window, so use this as selective hardening where patching is delayed.
4. Audit low-tier accounts and recent admin creation — Review subscriber signups, low-cost membership purchases, new membership levels, and any recently created administrator accounts for compromise artifacts. There is no mitigation SLA — go straight to the 365-day remediation window, but this is the fastest way to tell whether the bug was already abused.

Run this on the target WordPress host or inside the application container, pointing it at the WordPress document root. Example: bash verify-cve-2026-6895.sh /var/www/html; it needs only read access to the plugin files, so root is usually unnecessary unless your web root is locked down.

#!/usr/bin/env bash
# verify-cve-2026-6895.sh
# Check whether a local WordPress install appears vulnerable to CVE-2026-6895
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=vulnerable, 0=patched, 2=unknown/error

set -u

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

if [[ ! -d "$TARGET" ]]; then
  echo "UNKNOWN - path does not exist: $TARGET"
  exit 2
fi

PLUGINS_DIR="$TARGET/wp-content/plugins"
if [[ ! -d "$PLUGINS_DIR" ]]; then
  echo "UNKNOWN - wp-content/plugins not found under: $TARGET"
  exit 2
fi

# Compare versions using sort -V
ver_lt() {
  [[ "$1" != "$2" ]] && [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" == "$1" ]]
}

ver_le() {
  [[ "$1" == "$2" ]] || ver_lt "$1" "$2"
}

extract_version_from_file() {
  local f="$1"
  local v
  v=$(head -n 80 "$f" 2>/dev/null | sed -nE 's/^[[:space:]]*\*?[[:space:]]*Version:[[:space:]]*([^[:space:]]+).*/\1/p' | head -n1)
  if [[ -n "$v" ]]; then
    echo "$v"
    return 0
  fi
  return 1
}

extract_stable_tag() {
  local f="$1"
  local v
  v=$(sed -nE 's/^[[:space:]]*Stable tag:[[:space:]]*([^[:space:]]+).*/\1/p' "$f" 2>/dev/null | head -n1)
  if [[ -n "$v" ]]; then
    echo "$v"
    return 0
  fi
  return 1
}

find_plugin_dir() {
  local d
  for d in \
    "$PLUGINS_DIR/wishlist-member-x" \
    "$PLUGINS_DIR/wishlist-member" \
    "$PLUGINS_DIR/WishListMember"; do
    if [[ -d "$d" ]]; then
      echo "$d"
      return 0
    fi
  done

  d=$(find "$PLUGINS_DIR" -maxdepth 1 -mindepth 1 -type d \( -iname 'wishlist-member*' -o -iname 'wishlistmember*' \) 2>/dev/null | head -n1)
  if [[ -n "$d" ]]; then
    echo "$d"
    return 0
  fi
  return 1
}

PLUGIN_DIR=$(find_plugin_dir) || {
  echo "UNKNOWN - WishList Member plugin directory not found"
  exit 2
}

VERSION=""

# Preferred candidate files
for f in \
  "$PLUGIN_DIR/wishlist-member.php" \
  "$PLUGIN_DIR/wishlist-member-x.php" \
  "$PLUGIN_DIR/plugin.php" \
  "$PLUGIN_DIR/wpm.php" \
  "$PLUGIN_DIR/index.php"; do
  if [[ -f "$f" ]]; then
    VERSION=$(extract_version_from_file "$f" || true)
    [[ -n "$VERSION" ]] && break
  fi
done

# Fallback: first PHP file with a Version header near the top
if [[ -z "$VERSION" ]]; then
  while IFS= read -r -d '' f; do
    VERSION=$(extract_version_from_file "$f" || true)
    [[ -n "$VERSION" ]] && break
  done < <(find "$PLUGIN_DIR" -maxdepth 2 -type f -name '*.php' -print0 2>/dev/null)
fi

# Final fallback: readme stable tag
if [[ -z "$VERSION" ]]; then
  for f in "$PLUGIN_DIR/readme.txt" "$PLUGIN_DIR/readme.md"; do
    if [[ -f "$f" ]]; then
      VERSION=$(extract_stable_tag "$f" || true)
      [[ -n "$VERSION" ]] && break
    fi
  done
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - could not determine WishList Member version in $PLUGIN_DIR"
  exit 2
fi

if ver_le "$VERSION" "3.30.1"; then
  echo "VULNERABLE - WishList Member version $VERSION detected in $PLUGIN_DIR"
  exit 1
fi

if ! ver_lt "$VERSION" "3.31.0"; then
  echo "PATCHED - WishList Member version $VERSION detected in $PLUGIN_DIR"
  exit 0
fi

# This should be rare, but keeps ambiguous versions explicit.
echo "UNKNOWN - WishList Member version $VERSION detected; unable to map confidently"
exit 2

Sources

1. NVD CVE-2026-6895
2. Patchstack advisory for CVE-2026-6895
3. WPScan vulnerability entry
4. WishList Member 3.31.0 release notes
5. WishList Member API 2.0 documentation
6. Wordfence plugin record with active installs context
7. CISA Known Exploited Vulnerabilities catalog
8. FIRST EPSS API documentation