Attackers Exploit miniOrange SAML SSO WordPress Flaws to Log In as Any Admin

Attackers are actively trying to break into WordPress sites through two authentication-bypass flaws in the miniOrange SAML 2.0 Single Sign On plugin, and the most dangerous part is not the bugs themselves. It is that your WordPress dashboard, and most vulnerability scanners, may tell you the site is already patched when it is not.

The two flaws, CVE-2026-61979 (CVSS 8.1) and CVE-2026-15981 (CVSS 9.8), let an unauthenticated attacker forge a SAML login response and sign in as any existing WordPress user, including administrators. They were disclosed by WordPress security firm Patchstack, based on research by the DigitalOcean security team, and by August 25 both SecurityWeek and The Hacker News reported that opportunistic exploitation was already underway. The plugin, published by Xecurify, is an unauthenticated privilege escalation waiting to happen on any site that has not moved to the fixed build for its specific edition.

How the Bypass Works

Both bugs do the same thing from a defender's point of view: they convince the plugin that a signed SAML assertion is genuine when it is not, which is enough for the plugin to issue a valid WordPress session for whatever account the attacker names. No password, no existing session, and no user interaction are required.

CVE-2026-61979 is a signature algorithm confusion flaw. The plugin lets the incoming SAML response choose its own signature algorithm, so an attacker can switch verification from the expected RSA path to HMAC-SHA1. Because the identity provider's RSA public key is, by definition, public, the plugin can end up treating that public key as an HMAC secret, which lets a self-signed assertion pass as trusted. Patchstack notes miniOrange fixed this in version 17.0.5 on the Standard edition.

CVE-2026-15981 is simpler and scores higher. PHP's openssl_verify() returns 1 for a valid signature, 0 for an invalid one, and -1 when OpenSSL itself errors out, and the plugin checked that result loosely. Per the CVE.org record, the flaw stems from “the mo_saml_validate_signature() function performing a loose boolean check on the raw tri-state integer returned by PHP’s openssl_verify(), causing an error return value of -1 to be evaluated as truthy and therefore treated as a successful signature verification.” In plain terms, a deliberately malformed signature that trips an OpenSSL error is accepted as valid. That bug was fixed in Standard edition 17.0.6.

Neither flaw is an exotic memory-corruption chain. Both are logic errors in how trust is decided, the ordinary kind of mistake that hides in mature, heavily used code and turns a single-sign-on gateway into an open door.

Why Your Dashboard Says You're Patched When You Aren't

The reason this one is worth more than a line in a patch roundup is the distribution problem underneath it. miniOrange ships this plugin under one WordPress slug that actually contains seven separately versioned editions: Free, Premium, Standard, two Enterprise or All-Inclusive tiers, and VIP, plus multisite variants. No two share the same version number, so a version string on its own tells you nothing about whether you are exposed.

Only the free edition ever got a public advisory, which listed the fix in version 5.4.5 as a routine bugfix rather than a security patch. The six paid editions were patched with no changelog and no advisory at all. That gap is what makes the normal warning signals fail. Vulnerability databases keyed to the free-edition advisory read every paid install, on its higher version number, as already safe, and a vulnerable 16.x Standard install shows no available update in the WordPress dashboard because the fix lives on the 17.x line. Moving to it is a manual plugin upload, not a one-click update.

Patchstack was blunt about the fallout: “When a vendor runs seven independently numbered editions under one slug and patches six of them without a public advisory, the entire ecosystem downstream of them goes blind at once: databases, scanners, dashboards, and the site admins relying on all three.” This is exactly the failure mode that a mature vulnerability management program is supposed to catch, and it is a reminder that a scanner reporting “no known vulnerabilities” is only as good as the version data the vendor actually published.

A three-step affected check for the miniOrange SAML SSO flaws: confirm the plugin is active, compare your edition against the patched build, and do not trust the dashboard update prompt. Source: Patchstack advisory, August 2026. The CyberSignal.

How the Attacks Surfaced

The exploitation was caught not by a scanner but by a session that should never have existed. The DigitalOcean security team spotted an anomalous WordPress administrator session attempt coming from outside its trusted network and blocked it. According to Patchstack, “the attacker had already used the bypass to obtain a WordPress admin session cookie, but was stalled because the admin panel operations themselves sat restricted behind the trusted network.” That is defense in depth doing exactly the job it exists to do: the bypass worked, and a second control still stopped it short.

From there the activity looked broad rather than surgical. Patchstack recorded scanning against the miniOrange SSO endpoints from six IP addresses spread across Belgium, Nigeria, Germany and the United States, and characterized it as opportunistic. “Whoever is running this appears to be throwing the exploit at every site with the plugin installed without checking which edition or version is behind it,” the firm wrote. “The attacker does not need to know which edition you run, you do.” The Hacker News added that public proof-of-concept code exists, which shortens the window between disclosure and mass attempts. This is an account takeover story at its core, and the target is the highest-value account a site has, so the usual account takeover detection and response playbook applies to the admin tier here.

My read: the code bugs are patched, but the reporting failure is the part that will keep sites owned. When a vendor silently fixes six of seven editions, every automated assurance a defender leans on quietly turns into a false negative, and false negatives are worse than an honest “unknown.” My assessment, distinct from what the sources report as fact: the biggest population at risk is not the neglected sites but the diligent ones, the teams that ran a scan, saw a clean result, and reasonably moved on. This is the second serious WordPress-plugin flaw The CyberSignal has covered in under a week, after an unauthenticated upload-to-RCE bug in Elementor Pro, and the through-line is the same: a trusted plugin is not a safe input.

What Defenders Should Do

The fix is a version bump, but the surrounding checks are what turn a patch into actual assurance:

• Update the plugin to the fixed build for your exact edition, now. Match your edition against Patchstack’s table (Free 5.4.5, Standard 17.0.6, and edition-specific versions for the paid tiers) and expect to do it by manual upload rather than through the dashboard. If no fixed build is available to you yet, deactivate the plugin until one is.
• Audit every WordPress account for rogue admins. Look for administrator or high-privilege users you did not create, recently changed roles, and new accounts added around or after mid-August. A single unfamiliar admin is enough to justify a full incident review.
• Review authentication and SAML logs. Hunt for successful administrator logins from IP addresses outside your expected ranges, since that anomalous-session signal is what surfaced the whole campaign and does not depend on knowing your plugin version.
• Rotate administrator credentials and invalidate sessions. Reset passwords for admin accounts, force a re-login to kill any forged session cookies, and rotate any secrets those accounts could reach.

None of these steps depends on the vendor telling you that you were vulnerable, which is the point. On the questions defenders usually ask next: as of publication there are no publicly named victims, and the flaws are not listed on CISA’s Known Exploited Vulnerabilities catalog. Neither absence is reassurance given that exploitation is already being observed and proof-of-concept code is circulating.

Primary Documents

• Patchstack: One slug, seven editions (miniOrange SAML SSO, CVE-2026-61979 and CVE-2026-15981)
• SecurityWeek: WordPress Websites Targeted via MiniOrange Plugin Vulnerabilities
• The Hacker News: Attackers Target miniOrange SAML Flaws That Can Grant WordPress Admin Access
• CVE-2026-61979 record (CVE.org)
• CVE-2026-15981 record (CVE.org)