The forged SAML login your logs will call legitimate
Actively exploited miniOrange SAML bypasses (CVE-2026-15981, CVE-2026-61979) forge admin logins the IdP never saw and version scanners called patched.
Adopting SSO is usually described as moving authentication somewhere stronger. The identity provider gets the MFA policy, the conditional access rules, the hardware keys. What the description leaves out is the second half of every federation: a service provider that receives an assertion and decides, alone, whether to believe it.
Two authentication bypasses in the miniOrange SAML 2.0 Single Sign On plugin for WordPress put that decision on display. CVE-2026-61979 (CVSS 8.1) is a signature algorithm confusion: the plugin honored the SignatureMethod an attacker put in the SAML response, so choosing HMAC-SHA1 turned the IdP’s public RSA certificate — published in metadata, by design — into the HMAC signing secret. CVE-2026-15981 (CVSS 9.8) is simpler: PHP’s openssl_verify() returns 1 for valid, 0 for invalid, and -1 on error, and a loose boolean check in the plugin’s validation routine accepted -1 as a pass. Either path lets an unauthenticated attacker submit a forged assertion naming any user — including an administrator — and receive a valid session. Patchstack’s disclosure write-up documents probing from six IP addresses, and trade coverage confirms exploitation attempts are underway. Patched builds now exist for every edition of the plugin.
A WordPress plugin bug would not normally earn this space. What earns it is how cleanly the incident demonstrates two failures our industry keeps rediscovering: the log that looks right, and the version number that lies.
The verifier inherits the whole perimeter
Everything the IdP enforces — MFA, device posture, conditional access — compiles down to one moment at the service provider: is this assertion’s signature valid. If that check can be talked into a yes, none of the upstream controls were bypassed, because none of them were consulted. The IdP never saw a login. The attacker did not defeat the hardware key; they made it irrelevant.
Neither bug is exotic. Attacker-chosen algorithms sank JWT libraries a decade ago, and tri-state return values are a known trap in any verification API. That is the uncomfortable part: the failure mode is well documented, and it still shipped in the component whose only job is to be the perimeter. Teams audit their IdP configuration in depth and treat the relying party’s validation library as plumbing. The trust relationship reads the other way. The relying party is where federation is enforced or isn’t.
Each log is accurate. Together they describe a login that never happened
Consider what this forgery leaves behind. The WordPress side records a successful SSO login for the administrator: valid session, expected authentication method, plausible timestamp. The IdP records nothing, because it issued nothing. Each system’s log is internally consistent. Only the join reveals the problem — a session that exists on the service provider with no corresponding issuance at the identity provider.
Almost nobody performs that join. Most teams treat a successful federated login on the SP as proof the IdP approved it, which is precisely the assumption this bug class breaks. Per Patchstack’s account, the incident surfaced on August 16 when DigitalOcean’s security team noticed an anomalous WordPress administrator session attempt from outside their trusted network — at a time when no vulnerability database flagged the plugin they were running. The control that fired was session anomaly detection. Not signature validation, and not a scanner.
The version number said patched
The plugin ships under a single WordPress slug that contains seven separately versioned editions — free, standard, premium, enterprise, VIP, and multisite variants, each on its own version line. Public advisories and the CVE records described the free edition’s line. The paid editions carry much higher version numbers, so when databases encoded the vulnerable range, every paid install fell outside it. As Patchstack put it: “Every paid install reads as already patched.” DigitalOcean reproduced the bypass on Standard edition 16.1.9 — an install every scanner would have called clean.
This is worth sitting with, because vulnerability management is an evidence chain, and this incident broke it at the first link. A scanner does not observe code; it observes an identifier and a version string, then trusts the vendor’s packaging discipline to make that metadata mean something. Here the metadata was intact, the scan was performed correctly, the report said zero findings — and the finding was running in production. If your compliance posture cites clean scans as proof of patching, this is the failure shape that proof does not cover.
What we’d check this week
Not plugin-specific — this applies to any system that consumes federated assertions.
- Inventory your relying parties, not just your IdP. For each SAML integration, identify which library validates signatures and whether it enforces an algorithm allowlist or honors whatever the response declares.
- Pick one federated application and reconcile yesterday’s logins: every SP session should match an issuance event at the IdP. If you cannot run that join, you cannot detect assertion forgery at all.
- Ask whether a new administrator session from an unfamiliar network raises an alert anywhere. It was the control that actually worked here.
- For anything that gates authentication, check whether your vulnerability tooling verifies code or version strings. Where editions or forks share an identifier, version metadata is a vendor claim, not evidence.
- If you run WordPress estates: confirm whether any edition of this plugin is present, and update using Patchstack’s per-edition table — cross-line upgrades may require a manual install.
Sources
- CVE-2026-15981 — CVE record,
openssl_verify()return value mishandling - CVE-2026-61979 — CVE record, signature algorithm confusion
- One slug, seven editions — Patchstack disclosure write-up with exploitation indicators and per-edition patch table
- Attackers Target miniOrange SAML Flaws — The Hacker News, secondary coverage
Axowl builds identity and audit infrastructure where a session carries proof of its own issuance — which issuer, which assertion, verified how — so the join that catches a forgery is already in the record. How it works.