The WordPress Plugin Said It Was Up to Date. Attackers Could Still Become Admin.

The incident began on August 16, when DigitalOcean detected and blocked an administrator session attempt against a WordPress site from outside a trusted network. The network restriction worked, but only after the authentication layer had already failed: the attacker had obtained a valid administrator session cookie.

Research coordinated by Patchstack and DigitalOcean traced the access to two unauthenticated flaws in miniOrange’s SAML service-provider code. Both allowed a remote attacker to fabricate the proof that WordPress used to trust a federated login. An attacker who knew an existing administrator’s email address could sign in as that administrator without stealing a password, compromising the identity provider, or completing multi-factor authentication.

The technical defects are serious. The distribution and disclosure failure around them may be just as consequential. miniOrange ships seven independently versioned editions under one WordPress plugin slug. Public advisories initially described only the free edition, while six paid editions received fixes without a public advisory or useful changelog. Vulnerability databases and update dashboards could therefore tell customers that a vulnerable paid edition was safe or current.

The attacker did not need to compromise the identity provider

SAML single sign-on normally lets an identity provider such as Microsoft Entra ID, Okta, Google Workspace, OneLogin, Shibboleth, or ADFS issue a signed assertion about a user. A service provider, in this case the WordPress plugin, verifies that signature before creating a local session.

The attacker did not have to defeat Entra ID, Okta, or another identity provider. The flaws were in how the WordPress service provider evaluated the assertion it received.

The first vulnerability, CVE-2026-61979, is a signature-algorithm confusion flaw. The plugin allowed the incoming SAML message to choose the signature method. An attacker could select HMAC-SHA1, causing the plugin to treat the trusted identity provider’s RSA public key as an HMAC secret. A public key is not secret. An attacker could obtain it, use it to calculate a valid HMAC, and submit an assertion the plugin would accept.

The second vulnerability, CVE-2026-15981, turned an error into approval. PHP’s openssl_verify() function returns 1 for a valid signature, 0 for an invalid signature, and -1 when verification encounters an error. The plugin used a loose truth test. Because PHP treats -1 as truthy, a deliberately malformed signature that triggered an OpenSSL error could pass the check.

Either path could create a valid WordPress session for an existing local user. If the targeted account was an administrator, the attacker gained administrator privileges.

One plugin slug concealed seven security timelines

The free edition of miniOrange SAML SSO has 10,000 active installations in the WordPress plugin directory. Patchstack says miniOrange also has roughly 30,000 customers across six paid editions. Those paid products share the slug miniorange-saml-20-single-sign-on, but they do not share a version sequence.

That distinction is essential. A scanner that only knows the free edition was fixed in version 5.4.5 may see a paid installation on version 16.1.9 or 26.0.2 and conclude, incorrectly, that its higher number is safe. The WordPress dashboard may also show no update if moving to the fixed paid release requires crossing a product-version line through a manual upload.

Patchstack published the following edition-specific matrix after working with miniOrange:

DigitalOcean reproduced both vulnerabilities on Standard edition 16.1.9. That installation needed to move to the 17.x line to receive the fix, but the dashboard did not present the transition as an ordinary update. Administrators in the same position may have to download the corrected package and upload it manually.

Active exploitation is confirmed, but its scale is not

This is not merely a proof-of-concept story. DigitalOcean’s account documents an attacker obtaining a valid administrator session cookie before a trusted-network control blocked the resulting access. Patchstack also reported opportunistic probing from six source addresses in Belgium, Nigeria, the United States, and Germany. A public proof of concept exists for the free edition, and BleepingComputer reported active attacks on August 24.

The evidence supports confirmed exploitation and scanning. It does not yet establish mass compromise across the miniOrange customer base. Administrators should treat that distinction as a reason to investigate promptly, not as a reason to wait. Authentication bypasses often leave ordinary web access as their only initial trace, and a valid session cookie can make later actions look like legitimate administrator activity.

The control that worked was outside the login flow

DigitalOcean’s trusted-network restriction is an important part of this incident. SAML validation failed, but the attacker still could not use the administrator session from an untrusted location. That is a practical example of defense in depth containing an authentication failure after the identity layer had already been defeated.

Organizations should not assume that single sign-on and multi-factor authentication make a WordPress administration interface safe to expose broadly. Those controls protect the identity provider’s login. They cannot compensate for a service provider that accepts a fabricated assertion.

Where operations permit it, restrict /wp-admin and other sensitive management paths to trusted networks, managed devices, an access proxy, or a tightly controlled VPN. Session-aware controls, device posture, and independent network policy can stop an attacker even after a plugin creates a valid cookie.

What WordPress administrators should do now

1. Identify the exact miniOrange edition and version. Do not rely on the common plugin slug, a scanner’s generic version comparison, or the absence of an update notification.
2. Compare the installation against the edition-specific matrix. Upgrade to the listed fixed version or later. Be prepared to obtain a package from miniOrange and upload it manually when the correction crosses a version line.
3. Apply a temporary code-level mitigation if an immediate upgrade is impossible. Patchstack’s primary advisory describes how to reject the HMAC-SHA1 path and require openssl_verify() to return exactly 1. Treat this as a short-term measure, document it, and replace it with a vendor-supported build as soon as possible.
4. Hunt for unexpected administrator sessions. Review access logs and authentication records for SAML login activity from unfamiliar addresses, devices, countries, or networks, especially before the patch time.
5. Check what authenticated users changed. Review administrator creation, role changes, plugin and theme installations, file modifications, scheduled tasks, new API credentials, content changes, and unusual outbound connections.
6. Invalidate sessions after containment. Rotating WordPress authentication salts forces existing cookies to expire. Coordinate the change because it signs out legitimate users. Reset administrator credentials or identity-provider secrets when evidence indicates they were separately exposed, but do not mistake this flaw for proof that the identity provider itself was compromised.
7. Preserve evidence before cleaning up. Retain web, proxy, WordPress, identity-provider, and endpoint logs. A forged SAML assertion may be visible only briefly, while the session and its later actions can persist.

Silent patches created a vulnerability-data failure

The incident exposes a structural weakness in software inventory and vulnerability intelligence. One package identifier was used for seven commercial variants with unrelated version lines. Public records initially covered only one of them. The remaining fixes existed, but the metadata that defenders depend on did not describe them.

That breaks several common assumptions at once:

• A numerically higher version is not necessarily newer than the fixed release for another edition.
• An empty update queue does not prove that a paid plugin is current.
• A vulnerability database entry for a shared slug may not describe every product sold under that slug.
• A vendor can ship corrected binaries without giving customers enough information to recognize that they need them.

Security teams should record the product edition, release channel, entitlement, and update source for commercial WordPress plugins, not only the directory slug and version string. Vendors should publish edition-aware advisories and machine-readable affected ranges whenever products share an identifier. Silent fixes cannot protect customers who do not know that their installation is vulnerable or that a manual upgrade exists.

The miniOrange flaws were authentication failures, but the wider lesson is about trust in operational signals. The identity provider’s signature was trusted incorrectly. The dashboard’s absence of an update was trusted incorrectly. The vulnerability database’s version comparison was trusted incorrectly. DigitalOcean’s independent network restriction mattered because all three of those signals had already failed.

Sources

• Patchstack and DigitalOcean: One Slug, Seven Editions, published August 21, 2026.
• WordPress plugin directory: miniOrange SAML Single Sign On, accessed August 24, 2026.
• BleepingComputer: Hackers target WordPress sites in miniOrange auth bypass attacks, published August 24, 2026 at 3:26 PM, timezone not stated on the page.