Exploited miniOrange SAML flaws stay invisible to every vulnerability scanner

16 August 2026. DigitalOcean’s defense-in-depth controls flag an anomalous admin session originating outside the trusted network range. 25 August 2026. The Hacker News and BleepingComputer confirm active exploitation of the miniOrange SAML 2.0 Single Sign On plugin for WordPress. One month. That is how long sites running a paid edition stayed invisible to scanners while an attacker already held a valid administrator session.

The real subject of this story is not the severity of the two flaws, which is real: it is the distribution model that made them undetectable. miniOrange ships the plugin under a single slug, miniorange-saml-20-single-sign-on, that conceals seven independently versioned editions. The vendor filed a security advisory for the free edition only.

Two flaws that chain together

SAML single sign-on is how an enterprise WordPress site outsources authentication to a corporate identity provider: the plugin’s job is to trust only assertions that carry a valid signature. That trust boundary is exactly where both flaws sit.

The attack chains two distinct vulnerabilities, CVE-2026-61979 (CVSS 8.1) and CVE-2026-15981 (CVSS 9.8), which together let an unauthenticated visitor forge a SAML response and land in the WordPress admin panel without ever holding valid credentials.

CVE-2026-61979 is a signature algorithm confusion, a cryptographic class well documented since the JWT vulnerabilities of 2015 and a SimpleSAMLphp incident in 2018. The plugin reads the signature algorithm from the incoming SAML response, an attacker-controlled field, instead of enforcing the one configured by the site administrator. By specifying HMAC-SHA1, the attacker causes the plugin to treat the identity provider’s RSA public key as the shared HMAC secret. That public key is, by design, reachable from the metadata endpoint: the attacker fetches it, uses it as the secret, signs a forged assertion, and the plugin accepts it as legitimate.

CVE-2026-15981 exploits a subtler engineering error. PHP’s openssl_verify() function is tri-state: it returns 1 for a valid signature, 0 for an invalid one, and -1 when OpenSSL hits an internal error. The plugin evaluated that result with a loose boolean check rather than an explicit equality test. In PHP, -1 is truthy: a malformed signature that deliberately triggers a processing error returns -1, which the plugin treats as successful verification, and issues a valid WordPress session cookie for whatever account was targeted.

Chained, the two bugs provide a reliable, unauthenticated path from the public internet to a WordPress administrator account.

Seven editions, one slug

The most instructive part is not the code but the distribution. miniOrange maintains seven version lines under a single slug: the free edition from 3.x to 5.x, Premium from 11.x to 13.x, Standard from 15.x to 17.x, and Enterprise and VIP editions into the 20s, 25s and 30s. No two lines share a version range.

When miniOrange disclosed the two CVEs in July 2026, the advisories covered only the free edition, patched at version 5.4.5. The six paid editions, each with its own version line and its own fix, received no public advisory and no changelog entry.

Every vulnerability database works on the same principle: a slug, an affected version range, and a fixed version. When a scanner compared a Standard 16.1.9 install against the public fixed version of 5.4.5, it concluded, arithmetically right and factually wrong, that 16.1.9 was safe, because it is numerically greater. The same logic rendered every paid-edition site invisible to every public scanner. None of them were flagged as affected; all of them were.

What DigitalOcean caught that no scanner could see

The in-the-wild discovery did not come from a researcher but from an anomaly in DigitalOcean’s own infrastructure. On 16 August 2026, its defense-in-depth controls flagged an admin session from an address outside the trusted network range. The attacker had already obtained a valid admin session cookie through the flaw; the attack stalled only because admin operations sat behind network-level restrictions the cookie alone could not satisfy.

That is precisely the point: defense in depth, layers of access control that depend on no single gate, caught what no scanner had even attempted to flag. The DigitalOcean team then worked the exploit backward: reproducing both bypasses end to end against Standard 16.1.9, identifying 17.0.5 and 17.0.6 as the fixed versions on the Standard line, writing narrowly scoped hotfixes, and sharing the full analysis with Patchstack.

The scanning traffic, observed from addresses in Belgium, Nigeria, Germany and the United States, is opportunistic: it does not distinguish edition or version, it throws the exploit at every site running the plugin and waits to see who answers.

The model that makes the bug invisible

The blind spot closes in a way specific to the Standard 16.x line. Because the patched version is 17.0.6, a different major version from the vulnerable series, the WordPress dashboard shows no available update: the path from 16.x to 17.0.6 requires a manual plugin upload, not a click on the update button. An administrator who checked the dashboard, saw no prompt for the miniOrange plugin, and moved on received the same false all-clear as every scanner that looked at the same version number.

The scale is measurable. The free edition has roughly 10,000 active installs; miniOrange serves about 30,000 customers on paid plans. The plugin connects enterprise WordPress installs to identity providers such as Microsoft Entra ID, Okta, Google Workspace or OneLogin: the sites at risk are organizational deployments where a WordPress admin foothold opens a pivot into a network of connected corporate accounts.

What to do now

• Identify your exact edition and version. Do not trust the dashboard or the scanner: check the line (free, Premium, Standard, Enterprise, VIP) manually and compare against the version matrix published by Patchstack.
• Apply the fix manually if you are on Standard 16.x. The move to 17.0.6 does not happen through the normal update button: upload the patched plugin.
• Never treat an all-clear as proof of no flaw. The lesson here is structural: a vulnerability database is only as accurate as what the vendor chooses to publish.
• Layer your defenses. Restrict administrative operations to a trusted network and detect anomalous admin sessions: it was this layer, not the patch, that stopped the attack at DigitalOcean.

Verdict

If you run a paid edition of miniOrange SAML SSO, assume you are vulnerable until you have checked your exact version number against the Patchstack matrix. The scanner will tell you everything is fine; that is precisely the distribution bug it documents.

If you manage an enterprise WordPress site bound to an identity provider, generalize the lesson to any plugin that ships free and paid editions under one slug: advisory coverage does not track version coverage. A manual audit of the edition, combined with network controls around the admin panel, is the only safeguard that does not depend on the accuracy of published patches. Patch accuracy is a vendor input you cannot verify from outside; your own edition-level inventory and your own detection layers are the controls you actually own.

References

• Patchstack — One Slug, Seven Editions: the miniOrange SAML SSO bug
• TechTimes — Attackers Exploit WordPress SSO Plugin, 25 August 2026
• BleepingComputer — Hackers target WordPress sites in miniOrange auth bypass attacks
• The Hacker News — Attackers Target miniOrange SAML Flaws
• GitHub Advisory — CVE-2026-15981