miniOrange SAML SSO Vulnerability Lets Anyone Log In as Your WordPress Admin

A miniOrange SAML SSO vulnerability let unauthenticated attackers sign in to WordPress as any user, administrators included. Patchstack published the analysis on 21 August 2026, crediting the DigitalOcean security team that discovered the flaws.

Two critical bugs, CVE-2026-61979 and CVE-2026-15981, both rated CVSS 9.8, affect the miniOrange SAML 2.0 Single Sign On plugin. The real danger was not the code. It was that six paid editions were patched silently, so no vulnerability database flagged them.

Many sites therefore read as safe while staying exposed. miniOrange has since patched all seven editions.

miniOrange SAML SSO Vulnerability: Key Takeaway

• A miniOrange SAML SSO vulnerability let attackers forge a login as any WordPress admin, while silent patches on paid editions hid the risk from databases.

What the miniOrange SAML SSO vulnerability allows

SAML Single Sign On lets users log in to WordPress through an external identity provider. The miniOrange plugin verifies a signed SAML assertion, then grants the matching WordPress session. Both bugs break that verification, so an attacker can forge an assertion and walk straight into /wp-admin as any existing user.

The plugin is popular in enterprise settings, which raises the stakes. A single forged login can hand over full control of a site, its content, and its users.

DigitalOcean produced the root cause analysis for the paid editions, running it against Standard edition 16.1.9. As far as Patchstack can tell, it is the first published analysis for any paid edition.

CVE-2026-61979: signature algorithm confusion

The plugin lets the incoming SAML response choose its own signature algorithm. An attacker sets SignatureMethod to HMAC-SHA1, and the plugin then accepts the trusted RSA public key as the HMAC secret.

The catch is that a public key is public by design. An attacker fetches it from the identity provider metadata endpoint, uses it as the HMAC secret, signs a forged assertion, and the plugin treats the result as genuine. miniOrange fixed this issue in version 17.0.6 for the Standard edition.

CVE-2026-15981: an OpenSSL error read as success

The PHP function openssl_verify() returns three possible values: 1 for a valid signature, 0 for invalid, and -1 when OpenSSL itself errors. The plugin checked the result loosely, and in PHP the value -1 counts as true.

So a malformed signature that triggers an internal OpenSSL error gets accepted as valid. An attacker sends a deliberately broken signature, forces the error path, and the plugin waves it through. miniOrange fixed this issue in version 17.0.6 for the Standard edition. A third, lower severity issue that needs an administrator to click something was disclosed shortly after and is worth patching in the same pass.

One plugin slug, seven separate editions

Here is the twist that turned two fixed bugs into a widespread blind spot. miniOrange ships the plugin under one WordPress slug, miniorange-saml-20-single-sign-on, but that single listing contains seven independently versioned editions. No two share the same version number.

Patchstack obtained the full breakdown from the vendor:

To check whether your site is affected, find your edition, then compare your version against the “vulnerable up to” and “patched in” columns. A version number alone does not tell you which edition you run, since the bands overlap in the hundreds place but never in their meaning.

Why no vulnerability database flagged the paid editions

A WordPress vulnerability record carries a slug, an affected range, and a fixed version, and it assumes every version under that slug climbs together. Here the numbers climb in seven different directions at once.

The only public advisory covered the Free edition, which anyone can download from WordPress.org. It listed versions up to 5.4.4 as vulnerable and 5.4.5 as fixed. That record is correct on its own.

Applied to the whole slug, though, it breaks. Every paid install carries a higher number than 5.4.5, so every paid install reads as already patched. A genuinely vulnerable Standard site on 16.1.9 was reported as safe. Widening the range does not help either, because stretching it to catch 16.1.9 would falsely flag every patched Free site. One range cannot describe seven version lines. The six paid editions were patched with no public changelog and no advisory, which is the true root cause of the gap. This kind of silent patching problem echoes past cases like the critical ProjectSend vulnerability, where visibility lagged behind the fix.

No update appears in the WordPress dashboard

The situation gets harder still. If you run 16.1.9, your WordPress admin shows no available update, even though 17.0.6 exists on the Standard line you already license. The jump from a vulnerable 16.x to a patched 17.x is a manual plugin upload, because the normal update mechanism does not offer a move across version lines.

So an affected site owner faces three failures at once: no advisory to read, no database entry to warn them, and no update prompt in the dashboard. Every signal that usually flags a problem instead says everything is fine.

How DigitalOcean caught the miniOrange SAML SSO vulnerability

DigitalOcean did not find this by scanning plugins. Its defense in depth controls flagged an anomalous WordPress administrator session attempt from outside the trusted network and blocked it. The attacker had already used the bypass to obtain an admin session cookie, but stalled because sensitive admin operations sat behind the trusted network.

From there, the team reproduced the bypass on 16.1.9, traced both bugs to specific lines in the plugin and its bundled XML security library, worked out which paid versions were affected, wrote hotfixes, and published the full analysis. Scanning against the miniOrange SSO endpoints was observed from several IPs:

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
64.225.25.188     Clifton, US           Cloud / VPS

The spread points to opportunistic scanning rather than a targeted campaign. Attackers throw the exploit at every site with the plugin installed, without checking the edition. That is what makes silent patching dangerous, because the attacker does not need to know your edition. You do. Monitoring for logins from unexpected addresses is the same instinct behind stopping stolen WordPress credentials before they are used.

How to protect your WordPress site

If you run the miniOrange SAML 2.0 Single Sign On plugin, act quickly.

If you can update, do it. Find your edition in the table above and move to at least the version in the “patched in” column. Expect to do this by manual upload rather than through the dashboard, since the prompt is unlikely to appear.

If you cannot update immediately, DigitalOcean shared two narrow hotfixes. To block 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;
}

To fix the OpenSSL issue, replace the return at includes/lib/SAML2Core/XMLSecurityKey.php:494 with:

return openssl_verify( $ql, $hl, $this->key, $MG ) === 1;

These hotfixes buy time. They do not replace the vendor fix, which needs an allowlist for signature algorithms and broader hardening of the bundled XML library. Finally, review your logs for administrator sessions from IP addresses outside your expected ranges, since that signal surfaced the whole issue and does not depend on knowing your version.

Implications of the miniOrange SAML SSO vulnerability

Vulnerability databases are only as good as vendor disclosure

When a vendor patches six editions with no public advisory, everything downstream goes blind at once: databases, scanners, dashboards, and the admins who trust all three. Accurate alerting depends on knowing exactly what is installed, and here that information simply did not exist publicly until Patchstack obtained the vendor table.

Silent patching shifts risk onto users

A fix that ships without an advisory protects only the sites that happen to update. Everyone else stays exposed while believing they are safe. For a plugin that governs authentication, that gap is severe, because the payoff for an attacker is full administrator control.

Virtual patching scaled where reporting failed

A firewall rule that blocks the exploit pattern does not care which edition you run, so protection could cover all seven at once. The lesson is that detection based on version data can fail quietly, while behaviour based defenses and session monitoring keep working. Tools such as dedicated WordPress security monitoring illustrate that difference in practice.

One slug for many editions is a structural hazard

Bundling seven separately numbered products under a single listing broke the core assumption every WordPress vulnerability record relies on. It is a packaging decision with direct security consequences, and it deserves attention from any vendor running tiered editions.

Wrapping Up

The miniOrange SAML SSO vulnerability shows that the most dangerous part of a flaw is not always the flaw itself. Two critical authentication bypasses, CVE-2026-61979 and CVE-2026-15981, were fixed, yet six paid editions were patched in silence, so the sites most exposed had no way to learn they were at risk.

DigitalOcean closed that gap by publishing the analysis, the edition table, and the hotfixes, and Patchstack added all seven ranges to its database. Their choice to share turned a private save into an ecosystem wide one.

For site owners the action is clear. Confirm your edition, update to the patched version by manual upload if needed, apply a hotfix if you cannot update yet, and watch your logs for logins from unexpected addresses.

Questions Worth Answering

What is the miniOrange SAML SSO vulnerability?

• It is a pair of critical authentication bypass bugs in the miniOrange SAML 2.0 Single Sign On plugin that let an unauthenticated attacker log in to WordPress as any user, including administrators.

Which CVEs are involved and how severe are they?

• CVE-2026-61979 and CVE-2026-15981, both rated CVSS 9.8, which is critical.

How does the attack work?

• The attacker forges a signed SAML assertion by abusing weak signature checks, then lands in the WordPress admin panel as an existing user without valid credentials.

Who discovered and reported it?

• The DigitalOcean security team discovered the flaws and produced the root cause analysis, and Patchstack handled vendor follow up and the database update, publishing the findings on 21 August 2026.

Why did no vulnerability database flag the paid editions?

• The plugin ships seven separately versioned editions under one slug, and only the Free edition had a public advisory, so every paid install falsely read as already patched.

How do I know if my site is affected?

• Identify your edition, then compare your installed version against the “vulnerable up to” and “patched in” columns in the vendor table.

Why does my WordPress dashboard show no update?

• A vulnerable 16.x Standard install cannot jump to the patched 17.x line through the normal update mechanism, so no prompt appears and a manual upload is required.

Has miniOrange fixed the problem?

• Yes. All seven editions now have patched versions, and the fixed release for each is listed in the vendor table.

What can I do if I cannot update right away?

• Apply the two narrow hotfixes shared by DigitalOcean, and review your logs for administrator logins from IP addresses outside your expected ranges.

Is the vulnerability being exploited?

• Yes. Opportunistic scanning against the plugin endpoints has been observed, which is why prompt patching matters even if your specific edition feels obscure.