A Critical WordPress SSO Login Bypass Stayed Hidden in Six Untracked Plugin Editions

A critical authentication bypass in a WordPress single sign-on plugin was patched in six of its seven paid editions with no public disclosure at all, invisible to every vulnerability scanner that tracks the software, until DigitalOcean’s security team caught an attacker actively exploiting it on its own infrastructure. The plugin, miniOrange’s SAML Single Sign On, lets WordPress sites authenticate through SAML 2.0 identity providers such as Okta, Azure AD, and Google Workspace. Patchstack published the full findings on August 21, crediting DigitalOcean with the discovery, the root cause analysis, and fixes for editions the vendor had already patched quietly.

A Bypass DigitalOcean Almost Missed

On August 16, DigitalOcean’s defense-in-depth controls flagged an anomalous WordPress administrator session attempt originating from outside the company’s trusted network. According to Patchstack, the attacker had already used the bypass to obtain a valid admin session cookie, but the intrusion stalled because admin panel operations were separately restricted to DigitalOcean’s trusted network, a second control the attacker had not defeated. DigitalOcean’s team reproduced the bypass the next day against its own installation of the plugin, the Standard edition, version 16.1.9, and began tracing the bug to its root cause.

Two Ways to Log In as Anyone

The reproduction confirmed two separate authentication bypasses, each already logged in the National Vulnerability Database for the plugin’s free edition. CVE-2026-15981, rated 9.8 out of 10 (critical) with a low attack complexity, stems from how the plugin checks a SAML response’s digital signature. PHP’s openssl_verify() function is tri-state: it returns 1 for a valid signature, 0 for an invalid one, and -1 when OpenSSL itself throws an internal error. The plugin treated that result as a plain boolean, and in PHP, -1 evaluates as true. A malformed signature that tripped OpenSSL’s error path was accepted as a genuine one, letting an attacker submit a forged SAML response and log in as any existing user, including an administrator, without a password.

CVE-2026-61979, rated 8.1 (high severity) with a higher attack complexity, is a separate signature algorithm confusion bug. The plugin lets an incoming SAML response name its own signature algorithm. By setting that field to HMAC-SHA1, an attacker can trick the plugin into treating the identity provider’s public RSA key, which is public by definition, as a shared HMAC secret, then sign a forged assertion with a key the plugin already trusts. Patchstack traced both flaws to specific lines in the plugin’s bundled SAML2Core library and its own Utilities.php file.

Seven Editions, One Listing

Both CVEs were originally disclosed for the plugin’s free edition, distributed under the WordPress.org listing miniorange-saml-20-single-sign-on, which shows 10,000+ active installs. What DigitalOcean found is that miniOrange also sells six paid editions, Premium, Standard, a multisite Premium/Enterprise/All-Inclusive tier, a single-site Enterprise/All-Inclusive tier, and VIP editions for both single-site and multisite installs, all distributed under that same WordPress.org slug but versioned completely independently of the free tier and of each other. Free runs 3.x through 5.x. Premium runs 11.x through 13.x. Standard, the edition DigitalOcean was running, spans 15.x through 17.x. A version number alone does not indicate which edition a site is running.

That independence broke every vulnerability database’s coverage at once. Public advisories fixed the free edition at version 5.4.5. A scanner using that number as its cutoff sees a Standard-edition site on version 16.1.9, or a VIP site on 32.0.7, as already patched, since those version numbers are higher than 5.4.5, even though every one of those editions was still running the vulnerable code. miniOrange had patched all six paid editions quietly, according to Patchstack, with no changelog entry and no public advisory for any of them.

No Update Prompt, No Warning

The consequences reached beyond vulnerability scanners into the WordPress dashboard itself. A site running the vulnerable Standard edition 16.1.9 shows no pending update in its admin panel, even though the patched 17.0.6 has been available on the same product line the whole time, because WordPress’s update mechanism does not prompt across an edition’s separate version line. Patchstack says the only way to move from a vulnerable 16.x release to the patched 17.x release is a manual plugin file upload.

Patchstack also found evidence of opportunistic scanning rather than a single targeted campaign: it lists exploitation attempts against miniOrange SSO endpoints from IP addresses geolocated to Belgium, Nigeria, the United States, and Germany, a spread the firm says points to attackers testing the exploit against any site running the plugin, regardless of which edition or version answers back.

What to Do If You Run This Plugin

Patchstack’s advisory includes a table mapping each of the seven editions to its vulnerable version range and its patched version, and it recommends checking that table directly rather than trusting a dashboard update prompt or a scanner’s clean report. Site owners who cannot update immediately can apply two narrowly scoped code changes Patchstack published as temporary hotfixes: one rejects any SAML response that requests the HMAC-SHA1 algorithm, and the other requires openssl_verify() to return exactly 1 rather than any truthy value. Patchstack describes both as meant to buy time, not to replace the vendor’s own fix. The firm also recommends checking server logs for administrator sessions originating from unexpected IP ranges, the same signal that first surfaced the bug at DigitalOcean.

The timeline moved quickly once DigitalOcean flagged the issue. DigitalOcean reported the bypass and its edition-versioning discovery to Patchstack on August 17, the same day a bug bounty report against a separate installation of the same paid edition confirmed wider outside interest in the bug. miniOrange supplied the complete edition and version matrix on August 18, and Patchstack updated its vulnerability database with all seven ranges that day, three days before publishing the full writeup.

Patchstack frames the incident as a structural problem rather than a one-off vendor mistake. A vulnerability record normally assumes one WordPress.org slug maps to one climbing version number, an assumption that fails the moment a vendor ships several independently numbered products under a single listing without disclosing all of them. As the firm put it in its writeup: “When a vendor runs seven independently numbered editions under one slug and patches six of them without a public advisory, the entire ecosystem downstream of them goes blind at once: databases, scanners, dashboards, and the site admins relying on all three.”