← Back to Feed CACHED · 2026-08-26 00:35:55 · CACHE_KEY CVE-2026-61979
CVE-2026-61979 · CWE-266 · Disclosed 2026-08-13

Unauthenticated Privilege Escalation in SAML SP Single Sign On <= 5.4.3 versions.

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

The bouncer checks your forged ID because you told him to use crayons instead of UV light

CVE-2026-61979 is a signature algorithm confusion flaw in the miniOrange SAML 2.0 Single Sign On WordPress plugin (Free edition ≤ 5.4.4, Standard ≤ 17.0.5, Premium ≤ 13.0.3, and four other paid editions). The plugin reads the SignatureMethod attribute from an incoming SAMLResponse — an attacker-controlled field — rather than enforcing the algorithm configured in the IdP settings. An attacker specifies HMAC-SHA1, causing the plugin to feed the IdP's publicly known RSA X.509 certificate into PHP's hash_hmac() as a shared secret. Since the attacker knows that same certificate (it ships in IdP metadata or is embedded in the plugin config), they can compute a valid HMAC signature over a forged SAML assertion claiming any user identity, including administrator. The result: an unauthenticated, remote attacker receives a valid WordPress session cookie with full admin privileges.

The vendor tagged this HIGH 8.1 with AC:H, implying meaningful attack complexity. That rating is wrong. The public key is not a secret — it is literally published in IdP metadata and sometimes rendered in the plugin's own settings page. A working proof-of-concept is on GitHub, and Patchstack has documented active exploitation from six IPs across four countries. DigitalOcean's SOC caught a live attacker who had already obtained an admin session cookie via this flaw. Separately, the companion bug CVE-2026-15981 (OpenSSL tri-state boolean confusion, CVSS 9.8) offers an independent bypass path through the same code. The vendor's AC:H dramatically understates the real-world exploitability; this is effectively AC:L once you have the PoC and the public certificate.

"Public PoC and active exploitation turn HMAC key confusion into instant WordPress admin takeover."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify target running miniOrange SAML SSO

The attacker fingerprints WordPress sites for the miniOrange SAML SSO plugin using path probes (/wp-content/plugins/miniorange-saml-20-single-sign-on/) or the SAML metadata endpoint (/?option=saml_metadata). Shodan/FOFA dorks for WordPress SAML endpoints or mass HTTP probing with tools like httpx can enumerate targets at scale.
Conditions required:
  • Target WordPress site is publicly reachable
  • miniOrange SAML SSO plugin is installed and activated
Where this breaks in practice:
  • Only ~10,000+ free-edition installs on wordpress.org; paid editions add an unknown number
  • Plugin must be actively configured with a working IdP integration
Detection/coverage: WPScan, Wordfence, and Patchstack can identify the plugin and version via passive fingerprinting.
STEP 02

Obtain the IdP's RSA public certificate

The attacker retrieves the IdP's X.509 signing certificate. This is typically exposed via the IdP's SAML metadata URL (often publicly accessible), or sometimes rendered in the miniOrange plugin configuration UI if the settings page is not properly restricted. The certificate is public by design in SAML — it is not a secret.
Conditions required:
  • IdP metadata endpoint is accessible, OR the certificate is embedded in plugin config
Where this breaks in practice:
  • Some IdPs may restrict metadata to authenticated clients, but this is uncommon
STEP 03

Craft a forged SAMLResponse with HMAC-SHA1

Using the public PoC (available on GitHub), the attacker constructs a SAMLResponse XML document asserting the identity of admin (or any target username). The SignatureMethod is set to http://www.w3.org/2000/09/xmldsig#hmac-sha1. The attacker computes the HMAC-SHA1 signature using the PEM-encoded public key as the HMAC secret. The plugin's mo_saml_cast_key()XMLSecurityKey path in Utilities.php:246-281 and XMLSecurityKey.php:216-548 validates this signature as authentic.
Conditions required:
  • Public PoC or equivalent SAML crafting capability
  • Knowledge of a valid WordPress username (default: admin)
Where this breaks in practice:
  • None — the PoC automates the entire chain
Detection/coverage: WAF rules inspecting POST parameters for SAMLResponse with HMAC-SHA1 SignatureMethod can flag this. Wordfence has released a firewall rule.
STEP 04

Submit forged assertion and receive admin session

The attacker POSTs the crafted SAMLResponse to the plugin's ACS (Assertion Consumer Service) endpoint, typically /?option=saml_user_login. The plugin validates the forged HMAC signature against the public key, accepts the assertion, and issues a WordPress authentication cookie for the asserted identity. The attacker now has full wp-admin access.
Conditions required:
  • ACS endpoint is reachable (it always is if the plugin is active)
Where this breaks in practice:
  • Some WAFs may block oversized or malformed POST bodies
Detection/coverage: WordPress audit logs (e.g., WP Activity Log) will show a new admin session from an unexpected IP. DigitalOcean detected exploitation via anomalous admin session from untrusted network.
STEP 05

Post-exploitation: web shell, data exfil, or lateral movement

With WordPress admin access, the attacker can install a malicious plugin or edit theme PHP files to deploy a web shell. From there, they can exfiltrate database contents (including user credentials, PII, payment data for WooCommerce sites), pivot to the underlying server if PHP execution allows it, or use the compromised site as a watering hole or C2 relay.
Conditions required:
  • WordPress admin access achieved in step 4
Where this breaks in practice:
  • Hardened hosting environments (managed WordPress hosts) may restrict file writes or plugin installation
  • Server-level WAFs or EDR may detect web shell deployment
Detection/coverage: File integrity monitoring (OSSEC, Wazuh, Wordfence) can detect unauthorized file modifications. EDR on the underlying host can catch shell spawns from PHP processes.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationActive. Patchstack documented scanning/exploitation from 6 IPs across Belgium, Nigeria, US, and Germany. DigitalOcean SOC blocked a live attacker who obtained an admin session cookie via the Standard edition (v16.1.9). Pattern is opportunistic mass-scanning.
Proof of ConceptPublic. PoC for the free edition is available on GitHub. The Patchstack technical writeup includes full code-path analysis and two narrowly-scoped hotfix patches.
EPSS0.278% — relatively low, but this lags behind the active exploitation reality. Companion CVE-2026-15981 has EPSS 0.796% (54th percentile).
KEV StatusNot listed as of 2026-08-26. Likely pending; active exploitation meets CISA's inclusion criteria.
CVSS VectorVendor: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1). The AC:H is disputed — with public PoC and publicly-available signing certificate, effective complexity is Low, which would yield 9.8.
Affected VersionsFree ≤ 5.4.4 · Premium ≤ 13.0.3 · Standard ≤ 17.0.5 · Premium/Enterprise multisite ≤ 20.2.7 · Enterprise/All-Inclusive ≤ 26.0.2 · VIP single ≤ 32.0.7 · VIP multisite ≤ 35.0.6
Fixed VersionsFree 5.4.5 · Premium 13.0.4 · Standard 17.0.6 · Premium/Enterprise multisite 20.2.8 · Enterprise/All-Inclusive 26.0.3 · VIP single 32.0.8 · VIP multisite 35.0.7
Installed Base~10,000+ active installs (free edition on wordpress.org). Paid editions are not counted in that figure. Total exposure is unknown but the SAML SSO use case implies enterprise WordPress deployments.
Disclosure TimelineJuly 2026: initial disclosure and patches for free edition. August 13: CVE-2026-61979 published. August 16: DigitalOcean detects live exploitation. August 25: Patchstack publishes full technical writeup covering all 7 editions.
Reporting ResearcherDiscovered by DigitalOcean security team; full technical analysis by Patchstack (Dave Jong's team). Coordinated with miniOrange/Xecurify.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to CRITICAL (9.4/10)

The single most decisive factor is active exploitation in the wild combined with a public PoC against a zero-friction attack chain — the vendor's AC:H rating is factually incorrect because the required 'secret' (the IdP public key) is public by design, making real-world complexity effectively Low. The SAML SSO use case concentrates this plugin on enterprise WordPress deployments where admin takeover yields access to corporate content, internal portals, and potentially PII/payment data.

HIGH Vulnerability mechanism and exploitability
HIGH Active exploitation status
MEDIUM Total installed base across all 7 editions

Why this verdict

  • Active exploitation confirmed: Six IPs are mass-scanning, DigitalOcean blocked a live admin session takeover, and a public PoC exists on GitHub — this is not theoretical.
  • AC:H is factually wrong: The vendor's CVSS assumes the IdP public key is hard to obtain. It is not — it is published in IdP SAML metadata by design. With the PoC, exploitation is point-and-shoot, making effective AC:L and the true base score 9.8.
  • Unauthenticated full admin takeover: No credentials, no user interaction, no special network position required. Any internet-facing WordPress site running this plugin is exploitable.
  • Role multiplier: The miniOrange SAML SSO plugin is deployed specifically by organizations integrating WordPress with enterprise IdPs (Okta, Azure AD, ADFS). These are not hobby blogs — they are corporate intranets, customer portals, and e-commerce platforms. Admin takeover on these sites yields access to regulated data, PII, and payment information, and can serve as a pivot point into the corporate network. Blast radius per site is host-to-tenant level, but the enterprise context elevates the data impact significantly.
  • Vendor communication failure amplifies risk: Only the free edition received a public advisory. Six paid editions were patched silently without alerts, leaving paid customers unaware they need to update — a coverage gap that scanners cannot close.

Why not higher?

Already at CRITICAL 9.4. Not scored at 10.0 because the installed base is relatively small (~10K free installs plus unknown paid editions), the blast radius per exploitation is limited to a single WordPress site (not fleet-scale or identity-provider-scale), and the plugin is not a canonical high-value-role component like a DC, hypervisor, or EDR agent.

Why not lower?

Cannot be lower than CRITICAL given confirmed active exploitation, a public PoC, unauthenticated remote access with no user interaction, and full administrative takeover. The vendor's AC:H is demonstrably incorrect. Any enterprise running this plugin with SAML configured is immediately exploitable from the internet. Dropping to HIGH would ignore the live threat activity and the zero-friction attack chain.

05 · Compensating Control

What to do — in priority order.

  1. Deactivate the miniOrange SAML SSO plugin immediately if not business-critical — If SAML SSO on WordPress is not essential to operations, deactivating the plugin instantly eliminates the attack surface. This is the fastest mitigation — deploy within the noisgate CRITICAL mitigation SLA of 3 days.
  2. Apply the vendor patch to the correct edition — Update to the patched version for your edition (Free 5.4.5, Premium 13.0.4, Standard 17.0.6, etc.). Paid editions do NOT auto-update via wordpress.org — you must download the update from miniOrange directly. Deploy within 3 days per the noisgate CRITICAL mitigation SLA.
  3. Deploy a WAF rule blocking HMAC-SHA1 in SAMLResponse — Add a WAF rule (Cloudflare, ModSecurity, Wordfence) that inspects POST bodies to the ACS endpoint (/?option=saml_user_login) and blocks requests where the SignatureMethod contains hmac-sha1. Patchstack and Wordfence have published rules. Deploy within 3 days as a stopgap if patching is delayed.
  4. Restrict wp-admin and ACS endpoint access by IP — If your SAML IdP has a known egress IP range, restrict the ACS endpoint and /wp-admin to those IPs plus your corporate network via .htaccess, nginx config, or CDN rules. This limits who can submit forged SAMLResponses.
  5. Audit WordPress admin sessions and recently modified files — Review wp_users and wp_usermeta for unexpected admin accounts. Check wp-content/plugins/ and active theme directories for recently modified PHP files or unfamiliar files (web shells). Use WP-CLI: wp user list --role=administrator and find wp-content -name '*.php' -mtime -14.
What doesn't work
  • MFA on WordPress login does not help — the SAML assertion bypass creates a session cookie directly via the plugin's ACS handler, skipping the standard wp-login.php flow where MFA plugins hook in.
  • Rate limiting on wp-login.php is irrelevant — the attack targets the SAML ACS endpoint (/?option=saml_user_login), not the WordPress login page.
  • Disabling XML-RPC does not mitigate this — the attack uses standard HTTP POST to the ACS endpoint, not XML-RPC.
06 · Verification

Crowdsourced verification payload.

Run this script on the WordPress host (or any machine with SSH/file access to the WordPress installation directory). Invoke as: bash check_cve_2026_61979.sh /var/www/html (pass the WordPress root directory as the first argument). Requires read access to the plugin files — run as the web server user or root.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/bin/bash
# CVE-2026-61979 Checker — miniOrange SAML SSO Signature Algorithm Confusion
# Usage: bash check_cve_2026_61979.sh /path/to/wordpress
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

WP_ROOT="${1:-.}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/miniorange-saml-20-single-sign-on"

if [ ! -d "$PLUGIN_DIR" ]; then
  echo "UNKNOWN — miniOrange SAML SSO plugin not found at $PLUGIN_DIR"
  exit 2
fi

# Extract version from the main plugin file header
VERSION=$(grep -i 'Version:' "$PLUGIN_DIR/login.php" 2>/dev/null | head -1 | sed 's/.*Version:[[:space:]]*//' | tr -d '[:space:]')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not extract plugin version from login.php"
  exit 2
fi

echo "Detected miniOrange SAML SSO version: $VERSION"

# Check for the vulnerable code pattern: accepting attacker-controlled SignatureMethod
# In patched versions (5.4.5+), the plugin enforces the configured algorithm
if grep -q 'hmac-sha1\|HMAC.*SHA1\|cast_key' "$PLUGIN_DIR/includes/lib/mo-saml/Utilities.php" 2>/dev/null; then
  # Check if the fix is present (enforced algorithm check)
  if grep -q 'configured_algorithm\|enforceAlgorithm\|ALLOWED_ALGORITHMS' "$PLUGIN_DIR/includes/lib/mo-saml/Utilities.php" 2>/dev/null; then
    echo "PATCHED — version $VERSION contains algorithm enforcement fix"
    exit 0
  fi
fi

# Version-based check for the free edition
# Vulnerable: <= 5.4.4, Patched: >= 5.4.5
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"
if [ "$MAJOR" -lt 5 ] 2>/dev/null; then
  echo "VULNERABLE — version $VERSION is below the patched release (5.4.5)"
  exit 1
elif [ "$MAJOR" -eq 5 ] && [ "$MINOR" -lt 4 ] 2>/dev/null; then
  echo "VULNERABLE — version $VERSION is below the patched release (5.4.5)"
  exit 1
elif [ "$MAJOR" -eq 5 ] && [ "$MINOR" -eq 4 ] && [ "$PATCH" -le 4 ] 2>/dev/null; then
  echo "VULNERABLE — version $VERSION is below the patched release (5.4.5)"
  exit 1
elif [ "$MAJOR" -eq 5 ] && [ "$MINOR" -eq 4 ] && [ "$PATCH" -ge 5 ] 2>/dev/null; then
  echo "PATCHED — version $VERSION is at or above the fixed release"
  exit 0
elif [ "$MAJOR" -gt 5 ] 2>/dev/null; then
  # Paid editions use higher major versions — check known patched thresholds
  # Premium: 13.0.4+, Standard: 17.0.6+, Prem/Ent MS: 20.2.8+, Ent/AI: 26.0.3+, VIP: 32.0.8+, VIP MS: 35.0.7+
  echo "NOTE — Paid edition detected (v$VERSION). Known patched versions:"
  echo "  Premium >= 13.0.4 | Standard >= 17.0.6 | Prem/Ent MS >= 20.2.8"
  echo "  Ent/All-Inclusive >= 26.0.3 | VIP >= 32.0.8 | VIP MS >= 35.0.7"
  echo "UNKNOWN — manually verify your edition against the thresholds above"
  exit 2
fi

echo "UNKNOWN — could not determine patch status for version $VERSION"
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Patch or deactivate this plugin today — do not wait until Monday. CVE-2026-61979 is being actively exploited in the wild with a public PoC, and the attack chain is unauthenticated and trivial to execute. Under the noisgate mitigation SLA for CRITICAL findings, you have ≤ 3 days to apply a compensating control: either update to the patched version for your edition (Free 5.4.5, Premium 13.0.4, Standard 17.0.6, etc.), deactivate the plugin, or deploy a WAF rule blocking HMAC-SHA1 in SAMLResponse payloads. The noisgate remediation SLA gives you 90 days for full remediation, but given active exploitation, treat this as a patch-immediately situation — override the SLA and deploy the vendor fix within hours. Paid edition customers must download updates directly from miniOrange since wordpress.org only covers the free edition. After patching, audit your WordPress admin user list and filesystem for signs of compromise: unexpected admin accounts, recently modified PHP files, or unfamiliar plugins.

Sources

  1. Patchstack — Full Technical Writeup (7 Editions)
  2. The Hacker News — Active Exploitation Coverage
  3. BleepingComputer — Attack Campaign Details
  4. GitHub Advisory GHSA-wgjx-q85h-87v2 (CVE-2026-15981)
  5. WordPress.org — Plugin Page and Changelog
  6. WPScan — miniOrange SAML Vulnerability History
  7. GBHackers — Critical miniOrange SAML SSO Analysis
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.