The Wishlist Member plugin for WordPress is vulnerable to unauthorized modification of data due to a…

CVE-2026-6898 is a missing capability check in WishListMember3_Hooks::generate_api_key in WishList Member for WordPress. Affected versions are all releases up to and including 3.30.1; the fix is reported by Patchstack as 3.31.0. The vulnerable path lets an authenticated low-privilege user hit the wlm3_generate_api_key AJAX action, replace the plugin's REST API secret, and then use that new secret to create an administrator-capable membership level and an arbitrary admin user.

The vendor-style 8.8 HIGH score gets the *impact* right but overstates the *reach*. This is not unauthenticated remote code execution against every public WordPress site; it needs a valid account first and a commercial plugin with a relatively small exposed footprint. But because this is a membership plugin, the Subscriber prerequisite is materially weaker than it sounds in many real deployments, so this stays HIGH instead of dropping to medium.

Why this verdict

• Downgrade from 8.8: PR:L matters in the real world; the attacker needs a working account first, which is a meaningful prerequisite versus unauthenticated WordPress bugs.
• Not a full downgrade to medium: this is a *membership* plugin, so Subscriber accounts are often normal business objects, not rare internal users. That weakens the usual comfort defenders take from PR:L.
• Blast radius is total on a hit: once the REST API secret is rotated, the attacker can create an admin-capable membership level and arbitrary admin users, which is effectively site takeover.
• Exposure is narrower than commodity WordPress bugs: observed public footprint is in the hundreds of domains, not hundreds of thousands, which caps campaign value and keeps the score below the vendor baseline.
• Threat intel is quiet: no KEV entry, no exact public PoC located, and a very low EPSS all argue against pushing this into the top emergency tier today.

Why not higher?

This is not unauthenticated and not broadly applicable across the WordPress ecosystem; it only matters where WishList Member is installed and vulnerable. I also found no hard evidence of active exploitation or an exact public PoC for this CVE, which removes the biggest reason to score it as near-critical.

Why not lower?

On affected membership sites, the authentication requirement is often weak in practice because obtaining or creating a low-tier member account may be cheap, automated, or entirely expected. And once the bug is reached, the chain does not stop at data tampering; it ends in administrator creation and durable control of the site.

1. Block the AJAX action — Deploy a WAF or reverse-proxy rule that denies requests to /wp-admin/admin-ajax.php when action=wlm3_generate_api_key. This is the cleanest temporary choke point and should be in place within 30 days if you cannot patch immediately.
2. Freeze low-trust registrations — Disable open signup, free trials, or automated member onboarding on vulnerable sites until patched if the business can tolerate it. This attacks the most important prerequisite — a Subscriber account — and should be applied within 30 days where patching lags.
3. Alert on admin creation and role-map drift — Add detections for new administrator users, membership-level changes mapped to admin, and API key regeneration events. This will not prevent exploitation, but it gives you the best chance of catching follow-on abuse within 30 days while patch rollout finishes.
4. Constrain admin AJAX where possible — If member workflows do not require broad admin AJAX access, put path-based filtering or authenticated application proxy rules in front of /wp-admin/admin-ajax.php. Apply within 30 days on internet-facing membership sites that cannot be patched quickly.
5. Cull stale subscribers — Remove dormant member accounts, especially trial, coupon, and abandoned-payment users. Reducing the pool of low-privilege accounts lowers the exploitable population and should be completed within 30 days for exposed sites.

Run this on the target WordPress host or a mounted web root from an auditor workstation. Invoke it as bash check_wlm_cve_2026_6898.sh /var/www/html and use a user that can read the WordPress files; root is not required unless filesystem permissions are tight.

#!/usr/bin/env bash
# check_wlm_cve_2026_6898.sh
# Detects whether WishList Member for WordPress is vulnerable to CVE-2026-6898
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=vulnerable, 0=patched, 2=unknown

set -u

SAFE_VERSION="3.31.0"
WP_PATH="${1:-.}"
PLUGIN_SLUG="wishlist-member-x"
PLUGIN_DIR="$WP_PATH/wp-content/plugins/$PLUGIN_SLUG"

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

extract_version_from_file() {
  local f="$1"
  [ -f "$f" ] || return 1
  awk -F': *' '/^[[:space:]]*Version:[[:space:]]*/ {print $2; exit}' "$f" | tr -d '\r'
}

find_version() {
  local v=""

  if command -v wp >/dev/null 2>&1; then
    v=$(wp --path="$WP_PATH" plugin get "$PLUGIN_SLUG" --field=version 2>/dev/null | tr -d '\r')
    if [ -n "$v" ]; then
      printf '%s' "$v"
      return 0
    fi
  fi

  if [ ! -d "$PLUGIN_DIR" ]; then
    return 1
  fi

  for candidate in \
    "$PLUGIN_DIR/wishlist-member-x.php" \
    "$PLUGIN_DIR/wishlist-member.php" \
    "$PLUGIN_DIR/plugin.php" \
    "$PLUGIN_DIR/wlm.php" \
    "$PLUGIN_DIR/loader.php"
  do
    v=$(extract_version_from_file "$candidate")
    if [ -n "$v" ]; then
      printf '%s' "$v"
      return 0
    fi
  done

  v=$(grep -R -m1 -h -E '^[[:space:]]*Version:[[:space:]]*[0-9]+' "$PLUGIN_DIR" 2>/dev/null | head -n1 | sed -E 's/^[[:space:]]*Version:[[:space:]]*//; s/\r$//')
  if [ -n "$v" ]; then
    printf '%s' "$v"
    return 0
  fi

  return 1
}

VERSION="$(find_version)"
STATUS=$?

if [ $STATUS -ne 0 ] || [ -z "$VERSION" ]; then
  echo "UNKNOWN: Could not determine WishList Member version at $WP_PATH"
  exit 2
fi

if verlte "$VERSION" "3.30.1"; then
  echo "VULNERABLE: WishList Member version $VERSION is <= 3.30.1 (fixed in $SAFE_VERSION or later)"
  exit 1
fi

if verlte "$SAFE_VERSION" "$VERSION"; then
  echo "PATCHED: WishList Member version $VERSION is >= $SAFE_VERSION"
  exit 0
fi

echo "UNKNOWN: Detected version $VERSION but could not classify confidently"
exit 2

Sources

1. NVD CVE-2026-6898
2. Patchstack advisory for CVE-2026-6898
3. WishList Member changelog index
4. WishList Member 3.31.0 release notes
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS API documentation
7. WebTechSurvey WishList Member X footprint
8. CVE record page