Threat actors are actively exploiting two critical authentication bypass vulnerabilities in the miniOrange SAML 2.0 Single Sign-On plugin for WordPress. Chained, CVE-2026-61979 and CVE-2026-15981 allow an unauthenticated attacker to sign in as any WordPress user, including administrators — no credentials, no phishing, no user interaction.

The exploitation was identified through analysis by DigitalOcean and Patchstack, whose writeup carries the detail that makes this more than a routine plugin advisory.

Two bugs that are each other’s enabler

CVE-2026-61979 is an algorithm confusion flaw. The plugin reads the signature algorithm from the incoming SAML response rather than enforcing the algorithm it was configured to expect. An attacker can therefore specify HMAC-SHA1 — a symmetric algorithm — where the deployment intends asymmetric RSA verification.

This is the SAML analogue of the JWT alg: none class of bug, and it has the same root cause: treating a field controlled by the party being authenticated as an instruction about how to authenticate them.

CVE-2026-15981 is a PHP idiom failure. The plugin checks the return value of openssl_verify() for truthiness. That function returns 1 for a valid signature, 0 for an invalid one, and -1 on error. In PHP, -1 is truthy. A malformed signature that causes OpenSSL to throw an error is therefore accepted as a valid signature.

Either flaw is serious. Together they are a complete bypass: the first lets the attacker steer verification onto a path they control, the second ensures that when verification breaks, it breaks open.

Seven editions, six invisible

The Patchstack analysis surfaces a distribution problem that is arguably worse than the bugs themselves.

The free edition of miniOrange SAML SSO is installed on more than 10,000 WordPress sites and carries a CVE record. But the plugin ships in seven editions under variations of the same slug — Standard, Premium, Enterprise and other paid tiers sold directly by the vendor rather than distributed through the WordPress.org repository.

Six of those paid editions never appeared in any vulnerability database.

Consider what that means for a defender. Vulnerability scanners enumerate installed WordPress plugins and match them against CVE feeds. A site running the free edition gets flagged. A site running the Enterprise edition — deployed by exactly the kind of organization that buys enterprise SSO for its WordPress estate, meaning universities, government agencies, media companies and large enterprises — matches nothing, because there is nothing to match against.

The paid customers are simultaneously the higher-value targets and the ones their tooling cannot warn.

This is a recurring failure mode in the commercial plugin ecosystem. CVE assignment and vulnerability database coverage are anchored to the public repository. Software sold outside it exists in a coverage gap, and the gap widens precisely as the deployment becomes more valuable.

Why SAML plugins are worth attacking

WordPress SAML integrations exist so that an organization’s staff can access a WordPress property using corporate identity. That means the sites running these plugins are, by selection, the sites that matter: intranets, member portals, customer-facing properties for regulated businesses, university systems.

An administrator session on such a site delivers content control, plugin installation rights — and therefore arbitrary PHP execution — and access to whatever user data the site holds. On a membership or e-commerce property, that is the full customer database.

It also delivers something subtler: a trusted domain. A compromised WordPress admin on a legitimate corporate domain is an ideal staging point for phishing that will pass every reputation check, and for malware distribution from a host that no proxy will block.

What to do

  1. Update the miniOrange SAML SSO plugin immediately, on every edition. If you run a paid tier, obtain the patched build directly from miniOrange — the WordPress.org update mechanism will not serve it.
  2. Inventory your paid plugins. Any commercially licensed plugin distributed outside WordPress.org is outside your scanner’s coverage. Build a manual tracking list and subscribe to vendor security channels for each.
  3. Audit your administrator accounts. Look for new admin users, unexpected role escalations, and unfamiliar login events. Because the exploit produces a legitimate authenticated session, it leaves no failed-login signature.
  4. Review installed plugins and themes for anything added recently, and check wp-content for unexpected PHP files — the standard post-compromise persistence path.
  5. Rotate any secrets reachable from the WordPress host, including database credentials, API keys stored in plugin configuration, and SMTP credentials.

Because the attack yields valid sessions rather than brute-force noise, the absence of alerts is not evidence of safety. Sites that were internet-reachable and unpatched during the exploitation window should be examined for post-compromise artifacts rather than assumed clean.

Sources