The SMS Alert – SMS & OTP for WooCommerce

The SMS Alert – SMS & OTP for WooCommerce plugin (versions ≤ 3.9.5) exposes an unauthenticated endpoint in its OTP-based password reset flow that fails to validate the requester's identity before mutating the target user's profile. An attacker can submit a target username (including admin), overwrite the account's email address or phone number, then trigger an OTP reset to a channel they control — ending with a working admin login. The bug is a textbook CWE-287 (Improper Authentication) in the reset handler, not a subtle race or memory issue.

Vendor CRITICAL / 9.8 matches the vector on paper: network, no auth, no interaction, full CIA impact on a WordPress admin. But the vector ignores the plugin's own precondition — the vulnerable code path only fires on sites that have enabled OTP-based password reset AND have a phone number stored on the target account. That is a minority configuration even among installs of this specific plugin. Real-world severity is HIGH, not CRITICAL, but it is emphatically not something to defer.

Why this verdict

• Baseline is fair but overstated: vendor 9.8 correctly captures the auth-bypass class but ignores the plugin-side feature toggle that gates the vulnerable path.
• Friction — feature enablement: OTP-based *password reset* is a distinct setting from OTP for order notifications; most SMS Alert deployments use only the latter. Estimated <20% of installs are exposed.
• Friction — account precondition: target user must have a phone number on file. Many WP admins never populate that field, further narrowing to well below 10% of installs.
• Role multiplier: the affected component is a WooCommerce site — a payment-handling role. Chain success ends in admin takeover of a live e-commerce checkout, enabling Magecart skimmers and PII/PCI egress. Blast radius is per-site (tenant-scale), not fleet-scale, so the CRITICAL floor does not apply — but the HIGH floor does.
• No fleet-wide amplifier: this is not an IdP, hypervisor, CA, or kernel-mode agent. Compromise is one WordPress site per exploit; there is no lateral pivot into corporate identity unless the site is oddly integrated.
• Exploitation window is short: WP plugin auth-bypasses are commodity-weaponized fast. Absence of PoC today is not comfort — Patchstack/Wordfence signatures usually precede mass scanning by days, not weeks.

Why not higher?

Not CRITICAL because the vulnerable code path is gated by two opt-in conditions (OTP-reset feature enabled AND phone number on target account) that eliminate the majority of the installed base. There is no active exploitation, no KEV listing, and the affected component is not a canonical high-value-role system (IdP, hypervisor, CA, backup, kernel agent) that would force a CRITICAL floor.

Why not lower?

Not MEDIUM because when the chain does land it is fully unauthenticated remote admin takeover of a WooCommerce store — payment-card and PII exposure with regulatory (PCI-DSS, GDPR, state breach-notification) consequences. Historical priors on WooCommerce plugin auth bypasses show mass exploitation within days of PoC publication.

1. Disable OTP-based password reset in the plugin settings — Turns off the vulnerable code path entirely without uninstalling. Fastest mitigation — apply within the noisgate mitigation SLA of 30 days for HIGH, ideally same-day on any WooCommerce site handling payments.
2. Deploy Wordfence or Patchstack virtual patch / vPatch — Both vendors typically ship a firewall rule blocking the vulnerable AJAX action within 24-48h of disclosure. Enable auto-update for firewall rules and confirm the rule ID is active in your fleet.
3. Restrict wp-admin and admin-ajax.php at the edge to known IPs where feasible — For merchants with a small admin team, IP allow-list at Cloudflare/WAF layer blocks the attack outright. Not feasible for public checkout, but wp-admin restriction is.
4. Enforce a WordPress-layer 2FA plugin on all admin accounts — Even if the attacker resets the password, a second factor tied to the admin's real device stops login. Wordfence 2FA, miniOrange, or Two-Factor plugin all work; enforce, don't just enable.
5. Set define('DISALLOW_FILE_MODS', true) in wp-config.php — Blocks admin-level plugin/theme uploads and code editing — turns a successful admin takeover into a much lower-impact event. Combine with read-only deploy pipeline.

Run this from an auditor workstation with curl and jq available. It probes a target WordPress site to detect the plugin version. Invoke as: ./check_cve_2026_11387.sh https://store.example.com. No credentials required.

#!/usr/bin/env bash
# noisgate check: CVE-2026-11387 — SMS Alert for WooCommerce ≤ 3.9.5
# Usage: ./check_cve_2026_11387.sh <site_url>
# Exit 0: PATCHED, 1: VULNERABLE, 2: UNKNOWN, 3: usage error

set -u

if [ $# -lt 1 ]; then
  echo "Usage: $0 <site_url>" >&2
  exit 3
fi

SITE="${1%/}"
FIXED="3.9.6"
PLUGIN_README="$SITE/wp-content/plugins/sms-alert/readme.txt"

# Fetch plugin readme
BODY=$(curl -sSL --max-time 15 -A "noisgate-check/1.0" "$PLUGIN_README" || true)

if [ -z "$BODY" ]; then
  echo "UNKNOWN: could not retrieve $PLUGIN_README (plugin may not be installed, or path blocked)"
  exit 2
fi

# Extract Stable tag
VER=$(printf '%s' "$BODY" | grep -iE '^Stable tag:' | head -1 | sed -E 's/.*:\s*//; s/[[:space:]]+$//')

if [ -z "$VER" ]; then
  echo "UNKNOWN: readme.txt found but no Stable tag parsed"
  exit 2
fi

# Semver-ish compare against 3.9.6
verlte() { [ "$1" = "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -1)" ]; }

if verlte "$VER" "3.9.5"; then
  echo "VULNERABLE: sms-alert version $VER <= 3.9.5 (fix: $FIXED)"
  echo "NOTE: exploitability also requires the OTP-based password reset feature enabled in plugin settings."
  exit 1
else
  echo "PATCHED: sms-alert version $VER >= $FIXED"
  exit 0
fi

Sources

1. Wordfence Intelligence — plugin advisories
2. Patchstack WordPress vulnerability DB
3. SMS Alert plugin — WordPress.org
4. NVD — CVE-2026-11387
5. CISA KEV catalog
6. FIRST EPSS scoring
7. CWE-287 Improper Authentication
8. Wordfence — comparable WooCommerce Payments auth bypass