miniOrange SAML SSO Auth Bypass Chained in Live WordPress Attacks

Attackers are chaining two critical authentication bypass vulnerabilities in the miniOrange SAML 2.0 Single Sign On plugin for WordPress to forge SAML responses and log in as administrators. Patchstack has confirmed at least one successful compromise: on August 16, DigitalOcean blocked an anomalous WordPress administrator session that originated outside its trusted network, and the follow-on investigation traced it back to the plugin. The two flaws, CVE-2026-61979 and CVE-2026-15981, were fixed in July. The problem is that the vendor advisory covered only the free edition, so the roughly 30,000 customers running the six commercial editions were never told to patch.

How the chain works

The miniOrange SAML SSO plugin turns a WordPress site into a SAML service provider, letting staff authenticate through Microsoft Entra ID, Okta, Google Workspace, or OneLogin instead of separate WordPress credentials. The plugin's job on every login is narrow and critical: take the SAML response asserting who the user is, verify the identity provider actually signed it, and only then create a session. Both bugs sit inside that verification step.

CVE-2026-61979 is a signature algorithm confusion issue. The plugin reads the signature algorithm out of the incoming SAML response rather than enforcing the algorithm it was configured with. An attacker sets that field to HMAC-SHA1, which flips verification from an asymmetric check to a symmetric one. The plugin then uses the identity provider's RSA public key as the shared HMAC secret. That key is public by definition, published in IdP metadata, so the attacker already has the secret and can compute a signature the plugin accepts as authentic.

CVE-2026-15981 is the backstop failing. OpenSSL signature verification returns 1 for valid, 0 for invalid, and -1 for an internal error. The plugin treats -1 as success. Any malformed signature that pushes OpenSSL into an error state sails through validation. Chained together, the two flaws mean an attacker can mint a SAML assertion naming any user, including an administrator, and have the plugin honor it.

The disclosure gap is what turned a patched bug into an incident

According to Patchstack, both issues were publicly disclosed and fixed in July, and fixes were shipped for every edition. The vendor advisory, though, named only the free build. Administrators running paid editions had a patched release available and no reason to install it. Many took no action at all, which is the gap the current attacks are walking through.

miniOrange, created by Xecurify, is a family of seven plugins. The free single-site version accounts for roughly 10,000 downloads, and the six paid editions cover about 30,000 customers. The larger and better-funded install base is the one that was left in the dark. These are the fixed versions:

• Free, single site: 5.4.5
• Premium, single site: 13.0.4
• Standard, single site: 17.06
• Premium, Enterprise, and All-Inclusive, multisite: 20.2.8
• Enterprise and All-Inclusive, single site: 26.0.3
• VIP, single site: 32.0.8
• VIP, multisite: 35.0.7

What the confirmed attack looked like

The August 16 case involved the Standard edition running version 16.1.9, one release short of the patched 17.06. Attackers chained the two flaws to obtain a valid WordPress administrator session cookie. No password was guessed, no credential was phished, and no MFA challenge was presented, because from WordPress's perspective the identity provider had already vouched for the user. The anomaly that surfaced the intrusion was network-level: an admin session originating outside the trusted range.

Patchstack's telemetry shows exploitation attempts and opportunistic scanning from six IP addresses spread across Europe, Africa, and the United States. A proof-of-concept exploit targeting the free edition is publicly available, which means the barrier to entry is already low and the volume can rise sharply with no additional research effort from attackers.

Actions for this week

• Inventory every WordPress instance using miniOrange SAML SSO, including staging, marketing microsites, and anything a business unit stood up outside IT. SSO plugins tend to be installed once and forgotten.
• Compare the installed version to the fixed release for your specific edition and upgrade manually. Do not assume a paid license means automatic updates.
• If you cannot patch immediately, disable SAML login and fall back to local WordPress credentials with MFA until the update lands.
• Audit administrator accounts for additions or role escalations dating back to July, when the flaws became public knowledge.
• Invalidate all active sessions after patching. A session cookie obtained before the fix keeps working after it.
• Rotate the SAML configuration on the identity provider side and confirm the service provider entry only trusts the certificate you expect.

Detection and post-compromise checks

Because the bypass produces a legitimate-looking session, authentication logs alone will not flag it. The signals worth hunting are the ones that surrounded the DigitalOcean detection and the usual post-takeover behavior:

• Administrator sessions from IP addresses outside expected corporate or hosting ranges, which is the control that caught the confirmed case.
• SAML responses whose signature algorithm is HMAC-SHA1 rather than the RSA algorithm your IdP is configured to use.
• New administrator users, new application passwords, or REST API keys created without a matching change ticket.
• Plugin or theme files written outside a deployment window, plus any newly added PHP in the uploads directory.
• Scheduled task entries in wp_options and outbound connections from the web host to unfamiliar destinations.

The technical lesson is old: never let untrusted input choose the algorithm that validates it, and never treat an error return as a pass. The operational lesson is sharper. A patch that exists but is not announced to the customers who need it provides no protection. If you buy a commercial edition of an open-source plugin, do not rely on the vendor advisory feed alone. Track the free edition's changelog and your third-party vulnerability feed as well, because in this case those were the only channels telling the truth about the risk.