miniOrange SAML SSO admin bypass hits six paid editions

Two critical authentication bypass flaws in the miniOrange SAML 2.0 Single Sign On plugin let unauthenticated attackers forge SAML assertions and log in to WordPress as any existing user, including administrators. The research was reported by the DigitalOcean security team, with root cause analysis by DigitalOcean and coverage and vendor follow-up handled jointly with Patchstack. Both vulnerabilities carry a CVSS severity score of 9.8 and were publicly disclosed in July 2026. Although both have been fixed by the vendor, a large group of sites and many enterprise customers had no way of knowing they were affected, saw no pending update in their WordPress dashboard, and were not covered by any vulnerability database.

The first flaw, CVE-2026-61979, is a signature algorithm confusion issue. The plugin normally verifies a SAML response using a trusted RSA public key from the identity provider (IdP). But the plugin lets the incoming SAML response choose its own signature algorithm. An attacker can set the SignatureMethod to HMAC-SHA1, and the plugin then uses the public RSA key PEM as the HMAC secret. Because that public key is public by definition, the attacker can fetch it from the IdP metadata endpoint, use it as the HMAC secret, sign a forged assertion, and the plugin will accept it as genuine. The root cause analysis, run against Standard edition 16.1.9, points to Utilities.php lines 246-250, which read the attacker-selected algorithm and recast the RSA key, and XMLSecurityKey.php lines 308-314 and 546-548, which leave the PEM key material as raw bytes and then pass it directly to hash_hmac(). miniOrange fixed this in Standard edition 17.0.5.

The second flaw, CVE-2026-15981, comes from a loose check of the OpenSSL verification result. The function openssl_verify() returns 1 for a valid signature, 0 for an invalid signature, and -1 when OpenSSL itself hits an internal error. The plugin checked the result as a boolean, and in PHP the value -1 is truthy, so a malformed signature that trips an OpenSSL error path was accepted as valid. The relevant code paths are XMLSecurityKey.php lines 486-494, which return the raw tri-state result, and Utilities.php line 252, which evaluates it as a boolean. miniOrange fixed this in Standard edition 17.0.6. A third, separate issue was disclosed shortly after these fixes, but it requires an administrator to click something, so it sits below the first two in practical severity.

The plugin ships under one WordPress slug, miniorange-saml-20-single-sign-on, but that single listing quietly contains seven separately versioned product editions. The public advisories only ever covered the free edition. The vendor provided the following breakdown. Free (single site): first version 3.0.0, latest 5.4.7, vulnerable up to 5.4.4, fixed in 5.4.5. Premium (single site): first version 11.3.0, latest 13.1.0, vulnerable up to 13.0.3, fixed in 13.0.4. Standard (single site): first version 15.1.0, latest 17.1.0, vulnerable up to 17.0.5, fixed in 17.0.6. Premium/Enterprise/All-Inclusive (multisite): first version 20.0.0, latest 20.2.8, vulnerable up to 20.2.7, fixed in 20.2.8. Enterprise/All-Inclusive (single site): first version 25.0.0, latest 26.1.0, vulnerable up to 26.0.2, fixed in 26.0.3. VIP (single site): first version 32.0.0, latest 32.0.8, vulnerable up to 32.0.7, fixed in 32.0.8. VIP (multisite): first version 35.0.0, latest 35.0.7, vulnerable up to 35.0.6, fixed in 35.0.7. To check your site, find your edition and compare your version against the vulnerable and patched columns.

This versioning scheme is why no public vulnerability database caught these authentication bypasses. A typical vulnerability record assumes all versions under one slug climb together in one line. Here, they climb in seven separate bands. The only public advisory concerned the free edition, which was fixed at 5.4.5. Any paid install has a higher version number than that, so it reports as already patched. Widening the affected range does not help either, because free edition sites on 5.4.5 or later would then be falsely flagged as vulnerable. The correct fix is to record seven disjoint affected ranges on the same slug, which is what the database record now carries. The missing piece all along was the vendor table, which had not been published anywhere until this article.

The remediation story gets worse. If you are running Standard edition 16.1.9, your WordPress admin dashboard shows no available updates, even though 17.0.6 exists on the same Standard line you already have a license for. The upgrade path from a vulnerable 16.x to a patched 17.x is a manual plugin upload, because the typical WordPress update mechanism does not offer a cross-line jump. DigitalOcean confirmed both bugs on 16.1.9, a Standard release from the middle of that line, and the fix is 17.0.6. There is no 16.x patch coming.

DigitalOcean found the issue through defense in depth. There was no advisory to read, no database entry flagged the paid edition, and the plugin reported itself as fully up to date. An anomalous WordPress administrator session attempt from outside their trusted network was blocked. The attacker had already used the bypass to obtain a WordPress admin session cookie, but the admin panel operations themselves sat restricted behind the trusted network. From there, DigitalOcean reproduced the bypass end-to-end on version 16.1.9, traced both bugs to their root causes, determined which paid versions were affected, wrote the hotfixes, and shared the analysis for public benefit. Scanning activity against the miniOrange SSO endpoints has been observed from the following IP addresses: 207.211.214.41 (Brussels, Belgium, VPN/datacenter), 79.127.224.14 (Brussels, Belgium, VPN/datacenter), 102.91.71.83 (Abuja, Nigeria, mobile carrier), 162.243.116.148 (Secaucus, US, cloud/VPS), 84.201.6.54 (Frankfurt, Germany, hosting/datacenter), and 64.225.25.188 (Clifton, US, cloud/VPS). The spread suggests opportunistic scanning rather than a targeted campaign. The attacker does not need to know which edition you run; you do.

To protect your WordPress site, update the plugin to the version in the patched column for your edition, at minimum, and expect to do this by manual upload. If you cannot update immediately, DigitalOcean provides two narrow hotfixes. For the algorithm confusion, add this immediately after line 246 in Utilities.php: if ( XMLSecurityKey::HMAC_SHA1 === $MG ) { printf( 'HMAC SAML signatures are not supported.' ); exit; }. For the OpenSSL tri-state issue, replace the return at includes/lib/SAML2Core/XMLSecurityKey.php:494 with: return openssl_verify( $ql, $hl, $this->key, $MG ) === 1;. Both hotfixes are deliberately narrow and meant to buy time, not replace the vendor fix. A comprehensive fix needs an RSA allowlist for signature algorithms, removal of the public-key recasting path, a hard block on asymmetric keys entering HMAC branches, and hardening of the bundled XML security library. Als