The SAML Single Sign On – SSO Login plugin for WordPress is vulnerable to Authentication Bypass in all…

CVE-2026-15981 is an authentication bypass in the miniOrange SAML Single Sign On – SSO Login plugin for WordPress, affecting all versions ≤ 5.4.4 of the Free edition and equivalent versions across six paid editions (Premium ≤ 13.0.3, Standard ≤ 17.0.5, Enterprise ≤ 26.0.2, VIP ≤ 32.0.7, and both Multisite variants). The root cause is a classic PHP type-juggling mistake: openssl_verify() returns a tri-state integer — 1 (valid), 0 (invalid), or -1 (processing error) — but the plugin evaluates the result with a loose boolean check at XMLSecurityKey.php:494. In PHP, -1 is truthy, so a deliberately malformed signature that triggers an OpenSSL error is accepted as *valid*. An unauthenticated attacker sends a crafted SAMLResponse with a garbage signature and an attacker-controlled NameID pointing at the admin account; the plugin calls wp_set_auth_cookie() and hands over the session.

The vendor's CVSS 9.8 CRITICAL rating is accurate and if anything understates urgency given real-world conditions. This is not a theoretical risk: as of August 2026 active exploitation has been confirmed, with attackers chaining CVE-2026-15981 with a companion flaw (CVE-2026-61979, an HMAC algorithm-confusion bug in the same plugin) to forge complete SAML responses. A public proof-of-concept exists on GitHub targeting the Free edition, and scanning from at least six IPs across four countries has been observed. The plugin is an identity/authentication gateway — its entire purpose is to be the trust boundary — and a bypass here grants full WordPress admin, including the ability to install backdoor plugins, exfiltrate data, or pivot to the hosting infrastructure.

Why this verdict

• Unauthenticated remote, zero-click: The entire attack is a single POST request to a publicly accessible endpoint. No credentials, no phishing, no user interaction. Every sub-metric of the CVSS vector is worst-case. No friction-based downgrade is warranted for attack complexity.
• Active exploitation confirmed: Attacks observed in the wild since at least August 16, 2026, with scanning from multiple countries. A public PoC exists on GitHub. This is not theoretical — defenders are already behind the curve.
• Public PoC lowers the bar: The exploit is a single crafted HTTP POST. The type-juggling bug is trivially reproducible. Script-kiddie-grade exploitation is realistic.
• Role multiplier: The miniOrange SAML SSO plugin is an identity/authentication gateway by definition — it exists solely to control who gets authenticated. In enterprise deployments, WordPress sites behind SAML SSO are typically corporate intranets, customer portals, or partner-facing applications holding sensitive data. A bypass of this component grants admin-level access to the WordPress instance, enabling PHP code execution on the web server (blast radius: host → potentially lateral movement to database tier and shared hosting neighbors). For organizations using WordPress as an internal portal, compromise can yield credential material (SMTP, DB, API keys in wp-config.php) useful for further lateral movement. Because the component IS the auth boundary (≥95% of installs occupy the identity-gateway role by definition), the verdict floor is CRITICAL.
• Seven edition version lines create patching confusion: Vulnerability databases initially only covered the Free edition. Paid edition customers may believe they are unaffected when they are not. This operational gap increases real-world exposure duration.

Why not higher?

The score is already near-maximum at 9.6. A full 10.0 would require wormable or self-propagating characteristics, which this does not have — each target must be individually exploited. The install base of ~30,000 customers, while significant, is small relative to WordPress's overall footprint, limiting the total blast radius across the internet.

Why not lower?

Every downgrade pressure point fails to materialize: the attack is unauthenticated (no prior access needed), the endpoint is public by design (SAML ACS must be reachable), the exploit is trivial (single POST), exploitation is already happening in the wild, and the affected component is literally the authentication layer. There is no friction to justify any downgrade. Dropping below CRITICAL would require evidence that the exploit doesn't work reliably or that the exposed population is negligible — neither is true.

1. Disable the miniOrange SAML SSO plugin immediately if not business-critical — If SAML SSO can be temporarily replaced with native WordPress authentication or another SSO plugin, deactivating miniOrange eliminates the attack surface entirely. This is the fastest mitigation — deploy within the 3-day noisgate mitigation SLA for CRITICAL findings.
2. Apply the one-line source code hotfix to XMLSecurityKey.php — If you cannot update to the patched version immediately, change the openssl_verify() return check at line 494 of XMLSecurityKey.php from a loose boolean evaluation to a strict === 1 comparison: return openssl_verify($ql, $hl, $this->key, $MG) === 1; This neutralizes the tri-state bug. Deploy within 3 days.
3. Block HMAC-SHA1 signature algorithm in Utilities.php — To also neutralize the companion CVE-2026-61979, add a check after line 246 of Utilities.php to reject HMAC_SHA1 as a SignatureMethod. This prevents the algorithm-confusion attack that is being chained with CVE-2026-15981 in the wild. Deploy within 3 days.
4. WAF rule to inspect and block malformed SAMLResponse payloads — Deploy a WAF rule on the ACS endpoint URL that rejects POST requests where the SAMLResponse parameter contains a SignatureValue that fails base64 decoding or is suspiciously short/malformed. This is a defense-in-depth layer, not a primary fix. ModSecurity or Cloudflare custom rules can implement this.
5. Monitor for anomalous WordPress admin sessions — Alert on wp_login events for administrator accounts that do not correlate with a legitimate IdP-side authentication event. Check server access logs for POST requests to the ACS endpoint followed by /wp-admin access from the same IP. Use WP Activity Log or Sucuri plugin.

Run this script on each WordPress host (or from a management server with filesystem access to WordPress installations). Invoke as bash check_cve_2026_15981.sh /var/www/html where the argument is the WordPress root directory. Requires read access to the plugin directory. No WordPress admin credentials needed.

#!/usr/bin/env bash
# check_cve_2026_15981.sh — Detect miniOrange SAML SSO auth bypass (CVE-2026-15981)
# Usage: bash check_cve_2026_15981.sh /path/to/wordpress
# Exit codes: 0 = PATCHED or not installed, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

WP_ROOT="${1:?Usage: $0 /path/to/wordpress}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/miniorange-saml-20-single-sign-on"

if [ ! -d "$PLUGIN_DIR" ]; then
  echo "NOT INSTALLED — miniOrange SAML SSO plugin not found in $PLUGIN_DIR"
  exit 0
fi

# Check for the vulnerable loose boolean check in XMLSecurityKey.php
XML_SEC_FILE="$PLUGIN_DIR/includes/lib/SAML2Core/XMLSecurityKey.php"
if [ ! -f "$XML_SEC_FILE" ]; then
  # Try alternative paths used in different editions
  XML_SEC_FILE=$(find "$PLUGIN_DIR" -name 'XMLSecurityKey.php' -type f 2>/dev/null | head -1)
fi

if [ -z "$XML_SEC_FILE" ] || [ ! -f "$XML_SEC_FILE" ]; then
  echo "UNKNOWN — Could not locate XMLSecurityKey.php"
  exit 2
fi

# The vulnerable pattern: openssl_verify result used in loose boolean context
# The patched version uses === 1 strict comparison
if grep -qP 'openssl_verify\s*\(' "$XML_SEC_FILE"; then
  if grep -qP '===\s*1' "$XML_SEC_FILE"; then
    echo "PATCHED — XMLSecurityKey.php uses strict === 1 comparison for openssl_verify()"
    exit 0
  else
    echo "VULNERABLE — XMLSecurityKey.php uses loose boolean check on openssl_verify() return value (CVE-2026-15981)"
    # Also extract version for reporting
    MAIN_FILE=$(find "$PLUGIN_DIR" -maxdepth 1 -name '*.php' -exec grep -l 'Plugin Name' {} \; 2>/dev/null | head -1)
    if [ -n "$MAIN_FILE" ]; then
      VER=$(grep -oP 'Version:\s*\K[0-9.]+' "$MAIN_FILE" 2>/dev/null || echo 'unknown')
      echo "  Installed version: $VER"
    fi
    exit 1
  fi
else
  echo "UNKNOWN — openssl_verify() call not found in $XML_SEC_FILE; unexpected plugin structure"
  exit 2
fi

Sources

1. Patchstack — One slug, seven editions: the miniOrange SAML SSO bug
2. BleepingComputer — Hackers target WordPress sites in miniOrange auth bypass attacks
3. The Hacker News — Attackers Target miniOrange SAML Flaws
4. Patchstack Database — CVE-2026-15981
5. GitHub Advisory — GHSA-wgjx-q85h-87v2
6. NVD — CVE-2026-15981
7. THREATINT — CVE-2026-15981