miniOrange SAML SSO WordPress Vulnerability: One Slug, Seven Editions at Risk

Two critical vulnerabilities disclosed in July 2026 made it possible for an unauthenticated visitor to sign into a WordPress site as any existing user, administrator included, simply by sending a crafted SAML response to the miniOrange SAML 2.0 Single Sign On plugin. Both bugs, tracked as CVE-2026-61979 and CVE-2026-15981, were patched in the free edition and then quietly fixed in six paid editions with no public changelog. DigitalOcean's security team uncovered the gap on its own infrastructure, traced the root cause across the plugin's paid code paths, and shared the analysis with Patchstack because no vulnerability database had end-to-end coverage for the paid editions.

This matters to anyone running the plugin on a WordPress site, because the standard "is my site affected?" workflow depends on your installed version showing up in a public advisory. For many site owners, that workflow silently failed. The team that needs to act fastest is small IT groups and agencies managing enterprise SSO rollouts, since the versions they actually deploy were the ones never listed publicly.

Key Takeaways

• Two CVSS 9.8 authentication bypasses, CVE-2026-61979 and CVE-2026-15981, allow unauthenticated attackers to forge a SAML assertion and land in /wp-admin as any user, including administrators.
• The miniOrange SAML 2.0 Single Sign On listing on WordPress.org bundles seven independently versioned product editions under a single slug, so a "clean" report on your installed version is not reliable.
• Public advisories covered only the free edition, while the Standard, Premium, and Enterprise editions received silent fixes starting in versions 17.0.5 and 17.0.6 with no changelog entry.
• Vulnerable 16.x paid builds will not surface a managed update prompt in the WordPress dashboard, so a manual upgrade or hotfix is required.
• Exploitation attempts were observed and blocked in the wild, with DigitalOcean surfacing indicators of compromise that defenders can use.

What the Two miniOrange SAML SSO WordPress Vulnerability Bugs Actually Do

Both flaws sit on the path that verifies a signed SAML response from an identity provider. Each one gives a different way to make the plugin accept a forged assertion as genuine, so an attacker who can reach the SSO endpoint can step into a chosen account without supplying real credentials.

CVE-2026-61979: Signature algorithm confusion

The plugin lets the incoming SAML response choose its own signature algorithm. Because the public key is meant to be public, the "secret" is freely available from the IdP metadata endpoint.

CVE-2026-15981: OpenSSL error treated as success

PHP's openssl_verify() returns 1 for a valid signature, 0 for invalid, and -1 when OpenSSL itself errors internally. DigitalOcean traced this to XMLSecurityKey.php and Utilities.php. miniOrange shipped a fix in Standard edition 17.0.6.

A third, lower-severity issue was disclosed shortly after these fixes, rated UI:R on CVSS, meaning it requires an administrator to click something. It is worth bundling into the same patch cycle rather than treating as urgent.

Why One Slug Hid Seven Editions

The miniOrange SAML 2.0 Single Sign On plugin ships under a single WordPress slug, miniorange-saml-20-single-sign-on, but that listing quietly contains seven separately versioned product plans.

The result is a coverage gap: a site running an affected paid edition would receive a "not affected" verdict from public tools because the version string on the public advisory did not match.

Edition and Version Reference for the MiniOrange SAML SSO Plugin

The table below summarizes the editions tied to this slug and the version that introduces the fix for each of the two critical CVEs.

Important caveats: confirm the exact build number in your own plugin panel, since miniOrange increments editions independently. Plan for a manual upload through the plugin screen or an update pushed by your host or management tool.

What to Do If You Run the MiniOrange SAML SSO Plugin

Start by confirming which edition you actually have, since the slug alone does not tell you. If your build is below the fixed version for either CVE, you are exposed until you upgrade.

For administrators who need a fast stopgap while a full upgrade is scheduled, two narrowly scoped hotfixes are available: override the SignatureMethod selection on incoming SAML responses to force RSA verification only, and tighten the openssl_verify() check to treat any non-positive return value as a failure rather than accepting the tri-state result. Full release notes for the miniOrange SAML 2.0 Single Sign On plugin are worth requesting from the vendor if you operate under a paid plan, since they were not surfaced publicly.

For defense in depth, treat exposed SSO endpoints as high-value targets. Restrict /wp-admin and the SAML endpoints by IP where the IdP source ranges are known, add a web application firewall rule matching the documented indicators of compromise, and audit SSO logs for unfamiliar assertion IDs, unexpected SignatureMethod values, and OpenSSL-style verify errors that would normally indicate an attacker's malformed signature slipping through.

Why This miniOrange SAML SSO WordPress Vulnerability Case Matters Beyond One Plugin

The deeper lesson is structural. This is exactly the failure mode that left many enterprise rollouts running vulnerable 16.x builds without realizing it.

Operationally, the takeaway for any site owner is that "no alert" does not equal "safe" when an authentication plugin is in scope. Cross-check the installed build against the vendor's own changelog when one exists, ask the vendor directly when one does not, and keep a record of which edition and version is deployed so future incidents can be evaluated quickly.

Frequently Asked Questions

Was exploitation actually seen for these miniOrange SAML SSO bugs?

Yes. DigitalOcean reported that its defense-in-depth controls detected and blocked exploitation attempts on its infrastructure, and the indicators shared from that activity are intended to help other defenders spot similar activity. Treat the CVEs as actively targeted rather than theoretical.

My version of the plugin does not appear in any advisory. Am I safe?

Not automatically. Public advisories covered only the free edition for CVE-2026-61979 and CVE-2026-15981, while six paid editions under the same slug were patched silently in 17.0.5 and 17.0.6. Check your installed version against the edition table and confirm with the vendor that your specific build addresses both CVEs.

Will WordPress push the fix automatically?

For many affected paid editions, no. Vulnerable 16.x releases do not surface a managed update prompt, so a manual upload or an update pushed by your hosting provider is required. If you cannot upgrade immediately, apply the two narrowly scoped hotfixes described above and plan the full upgrade as soon as possible.

How do I know which edition of the plugin I actually have?

Open the plugin panel in your WordPress dashboard and read the version string shown next to miniOrange SAML 2.0 Single Sign On, then compare it against the fixed build numbers for each edition. When in doubt, log in to the vendor's customer portal and confirm your subscription tier and the corresponding build number.

What should I monitor after patching?

Watch the SSO endpoint logs for unfamiliar assertion IDs and unusual SignatureMethod values, especially HMAC-SHA1 attempts. Treat any openssl_verify() error followed by a successful login as suspicious, and review administrator sessions created outside normal working hours or from unfamiliar geographies as potential indicators of compromise.

Conclusion and Action Checklist

The miniOrange SAML SSO WordPress vulnerability is a reminder that authentication plugins deserve the same scrutiny as the rest of your stack, and that public advisory coverage is not always a complete picture.

• Identify the edition and exact build of miniOrange SAML 2.0 Single Sign On currently installed.
• Compare your build against 17.0.5 and 17.0.6 to confirm both CVE-2026-61979 and CVE-2026-15981 are addressed.
• If you are below the fixed build, apply the two narrowly scoped hotfixes as a stopgap and schedule the upgrade.
• Manually upload the patched build or have your host push it, since the vulnerable 16.x line will not prompt automatically.
• Review authentication and SSO logs for unfamiliar assertion IDs, unexpected SignatureMethod values, and anomalous administrator sessions.
• Document the edition and version in your asset register so future advisories can be matched against your deployment quickly.

For related reading on recent WordPress risk patterns and platform security controls, explore the WordPress vulnerability coverage on Cloudflare WAF and review the Imagick RCE patch guidance for another example of how silent updates can leave sites exposed.