Attackers Exploit WordPress SSO Plugin; Six Paid Editions Were Never in Any Vulnerability ...

Hackers are actively targeting a critical authentication bypass in the miniOrange SAML 2.0 Single Sign On plugin for WordPress — and the enterprise-linked sites most likely to run it have been flying blind, because the vendor shipped patches for six paid editions without filing a public security advisory for any of them. The gap left every vulnerability scanner, every managed-update dashboard, and every site administrator relying on either tool with a false all-clear — while attackers were already probing those same sites for a flaw that lets any unauthenticated visitor log in as a WordPress administrator .

The Hacker News and BleepingComputer both confirmed active exploitation today, with scanning traffic observed from IP addresses across Belgium, Nigeria, Germany, and the United States. The attack pattern is opportunistic: whoever is behind the scanning does not differentiate by edition or version. They are throwing the exploit at every site that has the plugin installed and waiting to see who answers. BleepingComputer confirmed active exploitation the day before, and The Hacker News confirmed it independently this morning.

The attack chains two distinct vulnerabilities, tracked as CVE-2026-61979 (CVSS 8.1) and CVE-2026-15981 (CVSS 9.8) , that together let an unauthenticated attacker forge a SAML authentication response and land in WordPress's administrator panel without ever possessing valid credentials.

The first flaw, CVE-2026-61979, is a signature algorithm confusion bug — a class of cryptographic attack with a well-documented history in authentication libraries dating to JWT vulnerabilities in 2015 and a SimpleSAMLphp incident in 2018 . Here, the miniOrange plugin reads the signature algorithm from the incoming SAML response itself — an attacker-controlled field — instead of enforcing the algorithm configured by the site administrator. By specifying HMAC-SHA1, an attacker causes the plugin to treat the identity provider's RSA public key as the HMAC shared secret. Since the RSA public key is, by definition, publicly accessible from the identity provider's metadata endpoint, the attacker already possesses it. They can fetch the key, use it as the HMAC secret, sign a forged SAML assertion, and the plugin accepts it as legitimate.

The second flaw, CVE-2026-15981, exploits a subtler engineering error. PHP's openssl_verify() function is tri-state: it returns 1 for a valid signature, 0 for an invalid one, and -1 when OpenSSL itself encounters an internal error. The miniOrange plugin evaluated that result with a loose boolean check rather than an explicit equality test. In PHP, -1 is truthy. A malformed signature that deliberately triggers an OpenSSL processing error therefore returns -1, which the plugin treats as a successful verification — and issues a valid WordPress session cookie for whatever account the attacker targeted. The Patchstack technical analysis traces both bugs to specific code paths in the plugin and its bundled XML security library.

Chained together, the two bugs provide a reliable, unauthenticated path from the public internet to a WordPress administrator account on any site running a vulnerable version.

The more consequential story here is not the bugs themselves — it is the distribution model that made them effectively invisible for more than a month after patches were shipped.

miniOrange ships the SAML SSO plugin under a single WordPress listing slug, miniorange-saml-20-single-sign-on , but that single slug quietly contains seven separately versioned product editions. The free edition runs from version 3.x to 5.x. The Premium single-site edition runs 11.x to 13.x. Standard single-site runs 15.x to 17.x. Enterprise and VIP editions climb into the 20s, 25s, and 30s. No two edition lines a version number range. The complete seven-edition version breakdown was not publicly available from any source until Patchstack obtained it directly from miniOrange on August 18.

When miniOrange disclosed CVE-2026-61979 and CVE-2026-15981 in July 2026, the advisories covered only the publicly downloadable free edition, patched at version 5.4.5. The six paid editions — each with independent version lines, each patched in a corresponding update — received no public advisory and no public changelog entry.

Every vulnerability database works on the same principle: a slug, an affected version range, and a fixed version. When a scanner compared an installation running Standard edition version 16.1.9 against the public advisory's fixed version of 5.4.5, it correctly concluded — and incorrectly — that 16.1.9 was safe, because 16.1.9 is numerically greater than 5.4.5. The same logic rendered every paid-edition site invisible to every public scanner. None of them were affected according to any database. All of them were.

The blind-spot compounds in a way that is specific to the 16.x Standard line. Because the patched Standard edition is version 17.0.6 — a different major version from the vulnerable 16.x series — the WordPress admin dashboard does not surface an available update. The update path from vulnerable 16.x to patched 17.0.6 requires a manual plugin upload, not a click on the standard update button. A site administrator who checked their dashboard, saw no update prompt for the miniOrange plugin, and moved on to other tasks was given the same false all-clear as every scanner that looked at the same version number. The Patchstack advisory documents this dashboard gap explicitly as a compounding factor.

The plugin's free edition has approximately 10,000 active installs on WordPress.org. miniOrange serves approximately 30,000 customers across its paid plans. The plugin connects enterprise WordPress installations to corporate identity providers — Microsoft Entra ID, Okta, Google Workspace, OneLogin — which means the sites at risk are organizational deployments where an attacker gaining WordPress admin access can pivot into a network of connected corporate accounts.

The discovery of in-the-wild exploitation did not come from a researcher. It came from an anomaly that showed up in DigitalOcean's own infrastructure.

On August 16, 2026, DigitalOcean's defense-in-depth controls flagged an anomalous admin session originating from outside their trusted network range. An attacker had already used the plugin flaw to obtain a valid WordPress admin session cookie. The attack stalled only because the admin panel operations themselves sat behind network-level access restrictions that the session cookie alone could not satisfy. Defense-in-depth — layers of access control that did not depend on any single gate — caught what no vulnerability scanner had even attempted to flag.

The DigitalOcean security team then worked backward through the exploit: reproducing both authentication bypasses end-to-end against Standard edition 16.1.9, tracing each flaw to specific code paths in the plugin and its bundled XML security library, identifying 17.0.5 and 17.0.6 as the fixed versions on the Standard line (versions the vendor had not publicized), writing narrowly-scoped hotfixes for each bug, and sharing their full root cause analysis, hotfixes, and indicators of compromise with Patchstack for broader publication.

Patchstack then contacted miniOrange directly. On August 18, miniOrange provided the complete edition-and-version matrix. Patchstack subsequently updated its vulnerability database with all seven version ranges — the first time any public database had covered the paid editions. Between the public disclosure of the CVEs in July and August 18, every paid-edition site on the planet was, in every database's view, already patched.

Administrators running any edition of the miniOrange SAML 2.0 Single Sign On plugin should take the following steps immediately.

Identify your edition and version. Use the table below. Version numbers alone are insufficient — you must know your edition, as each spans a different range. The WordPress admin's Plugins screen shows the installed version; your license documentation identifies the edition tier.

Premium (single site)

Standard (single site)

Premium/Enterprise/All-Inclusive (multisite)

Enterprise/All-Inclusive (single site)

The complete Patchstack edition table is the authoritative source for these version ranges.

Update to the patched version. Apply the fix in the Patched In column. If running a vulnerable 16.x Standard release, expect to upload the plugin manually from the miniOrange license dashboard — the WordPress admin will not prompt you.

If an immediate update is not possible , DigitalOcean has published two code-level hotfixes targeting the specific exploit paths. For the algorithm confusion bug, add a single check immediately after line 246 in Utilities.php that rejects HMAC-SHA1 as a valid signature algorithm. For the OpenSSL tri-state bug, replace the loose boolean return at XMLSecurityKey.php:494 with an explicit strict equality check against 1. Both hotfixes in the Patchstack advisory are a temporary measure, not a substitute for the vendor patch.

Check your authentication logs. Look for WordPress administrator sessions originating from IP addresses outside your expected ranges or trusted network. This signal — an anomalous admin session cookie appearing from an unfamiliar IP — is precisely what allowed DigitalOcean to detect the exploit attempt, and it does not depend on knowing your plugin version. The six Patchstack-identified scanning IPs — 207.211.214.41, 79.127.224.14, 102.91.71.83, 162.243.116.148, 84.201.6.54, and 64.225.25.188 — are available as starting points for log review.

The most important lesson from this incident is not miniOrange specifically. It is a reproducible structural gap in how the WordPress vulnerability ecosystem handles products that ship multiple independently versioned editions under a single slug.

Every scanner, database, and managed-update system that evaluates WordPress plugins assumes one version line per slug. One affected range, one fixed version. That assumption breaks entirely when a vendor distributes seven independent version lines — each with a different numeric range — under the same identifier. The database record is technically accurate for the edition it was written for, and technically wrong for every other edition. Widening the range does not fix the problem: stretching the advisory to catch 16.1.9 would incorrectly flag every free-edition site already patched at 5.4.5 as still vulnerable.

The fix Patchstack settled on — seven disjoint ranges in one record, sourced from the vendor's complete edition table — required the vendor's cooperation to produce. Until miniOrange provided that table on August 18, no public source had it. Any vendor, deliberately or inadvertently, can reproduce this blind spot simply by shipping a multi-edition product under a single slug and patching paid tiers without filing separate advisories.

For organizations running enterprise WordPress deployments that integrate with corporate identity providers, that structural gap is a reason to treat vendor-reported patch status with skepticism and to layer in independent controls — anomaly detection on admin sessions, network-level restrictions on admin operations, and periodic manual verification of plugin versions against a full edition mapping — rather than relying on dashboard update prompts as the definitive signal that a product is safe.

Two critical flaws — CVE-2026-61979 and CVE-2026-15981 — in the miniOrange SAML 2.0 Single Sign On plugin for WordPress allow any unauthenticated internet user to forge a SAML authentication response and log in as any WordPress user, including administrators, with no valid credentials required. The plugin is used by enterprise WordPress sites that have integrated corporate identity providers such as Microsoft Entra ID, Okta, and Google Workspace. The free edition has approximately 10,000 active WordPress.org installs; the vendor serves approximately 30,000 customers across paid editions. Any site running a vulnerable edition version (see the table above) is at risk and should treat the patch as critical-priority.

If your site runs a paid edition of the plugin, every major vulnerability database and scanner listed it as unaffected — because the vendor's only public security advisory described the free edition fix (version 5.4.5) and the paid editions use entirely different version number ranges. A scanner comparing a paid Standard edition at version 16.1.9 to the public advisory's fixed version of 5.4.5 correctly concluded 16.1.9 was larger — and incorrectly concluded it was patched. The WordPress admin dashboard similarly does not surface the paid-edition updates as available, because updating from 16.x to 17.0.6 requires a cross-line manual upload. Patchstack updated its database with all seven edition ranges on August 18, after miniOrange provided the full edition matrix directly. The gap between July disclosure and August 18 is when every paid-edition site was flying blind.

Yes. The structural gap that allowed paid-edition sites to be missed is not unique to miniOrange. Any WordPress plugin vendor that ships multiple independently versioned editions under a single listing slug — and patches paid tiers without filing public security advisories for each — produces the same ecosystem blind spot. Vulnerability databases are only as accurate as the data vendors choose to publish. For organizations running enterprise WordPress with plugins that have paid and free tiers, the practical safeguard is to verify your exact edition and version manually against the vendor's full version matrix, rather than relying solely on scanner or dashboard output. Defense-in-depth network controls — anomaly detection on admin sessions, trusted-network restrictions on administrative operations — provide a detection layer that does not depend on patch-level accuracy.

Signature algorithm confusion is a class of cryptographic attack that exploits implementations which accept the choice of signing algorithm from an attacker-controlled input instead of enforcing the algorithm the system has configured. In the SAML context, the attack causes the service provider to treat an identity provider's RSA public key — which is publicly accessible by design — as a symmetric HMAC secret. Because the attacker already has the public key, they can produce a forged signature the service provider accepts as genuine. The same class of flaw appeared in JWT libraries in 2015 and in SimpleSAMLphp in 2018. It is a recurring pattern in XML and token-based authentication libraries because the API designs that enable it — accepting algorithm as a parameter, not differentiating between symmetric and asymmetric key types — are widespread. The definitive fix requires both an algorithm allowlist enforced by the server and a strict key-type check that prevents asymmetric key material from entering symmetric signature routines.