The active exploitation of vulnerabilities in the miniOrange SAML 2.0 Single Sign On plugin for WordPress is particularly serious because the affected component sits directly in the authentication path. The plugin is designed to allow WordPress users to authenticate through trusted identity providers such as Microsoft Entra ID, Okta, Google Workspace or OneLogin instead of maintaining separate WordPress credentials. That centralises identity management and can improve security when implemented correctly, but it also means that a flaw in SAML validation can undermine the entire login process. In this case, attackers are exploiting two vulnerabilities, CVE-2026-61979 and CVE-2026-15981, to forge SAML authentication responses and obtain administrator access without possessing legitimate credentials.

CVE-2026-61979 affects the way the plugin handles the signature algorithm declared inside an incoming SAML response. Instead of strictly enforcing the cryptographic algorithm configured locally for the trusted identity provider, the vulnerable implementation accepts an algorithm supplied through attacker-controlled SAML content. This creates an algorithm-confusion problem. An attacker can choose HMAC-SHA1, causing the plugin to reinterpret the identity provider’s RSA public key as though it were a symmetric HMAC secret. The RSA public key is, by design, public information, so once it is incorrectly treated as the shared signing secret, the attacker can create a forged SAML signature that the vulnerable plugin may accept as legitimate.

This is a particularly useful example of why cryptographic validation must never allow the untrusted message to decide which security algorithm will be used to validate that message. The identity provider and service provider should agree beforehand on the expected signing algorithm and keys, and those values should be enforced by local configuration. Allowing the sender to choose a weaker or structurally different verification mechanism creates the equivalent of allowing someone presenting an identity document to choose the rules by which that document will be considered authentic. The mathematics may still be functioning perfectly; the application has simply asked the wrong cryptographic question.

CVE-2026-61979 affects miniOrange SAML SP Single Sign On versions through 5.4.3 in the free branch and is classified as an unauthenticated privilege-escalation vulnerability. The issue was fixed beginning with 5.4.4 for that branch. Although its published CVSS score is 8.1 rather than 9.8, the practical impact can still be complete administrator account takeover when the required conditions are satisfied. This is another reason organisations should avoid using CVSS as the sole prioritisation mechanism. A remotely exploitable authentication weakness in a public WordPress SSO system can have a much larger operational impact than the numerical difference between 8.1 and 9.8 might suggest.

CVE-2026-15981 is a second and independently dangerous authentication bypass in the same plugin. The flaw exists in the way the plugin interprets the return value from PHP’s `openssl_verify()` function. That function can return three different values: 1 when a signature is valid, 0 when it is invalid, and -1 when OpenSSL encounters an error. The vulnerable code performs a loose boolean check instead of explicitly requiring the result to equal 1. In PHP, -1 evaluates as true in a boolean context, so a deliberately malformed signature that causes OpenSSL to return an error can be mistakenly treated as a successful signature verification.

That programming error is small in terms of code but enormous in terms of security consequence. An unauthenticated attacker can submit a crafted SAML response containing a chosen NameID and a malformed signature designed to trigger the OpenSSL error condition. Because the plugin treats the error as success, the normal cryptographic verification step is bypassed. The plugin can then call WordPress authentication routines and issue a valid authentication cookie for the targeted account, including an administrator account. CVE-2026-15981 affects versions through 5.4.4 of the free SAML Single Sign On plugin and carries a CVSS 3.1 score of 9.8.

The vulnerability illustrates a broader secure-coding lesson about security-sensitive APIs that return more than simple true-or-false values. Developers must handle each possible result explicitly. A cryptographic verification function returning “error” does not mean “valid enough.” Any unexpected state in authentication or cryptographic validation should fail closed. In this case, one loose comparison transformed an internal OpenSSL error into permission to authenticate as another user. The computer did exactly what the code requested, which remains one of software security’s less comforting traditions.

The two vulnerabilities become particularly concerning because they can be chained. CVE-2026-61979 gives attackers a way to manipulate the signature algorithm and forge SAML material, while CVE-2026-15981 creates another route for bypassing signature verification entirely by forcing an error state. Patchstack’s investigation found that attackers were chaining the two issues against the paid Standard edition of the plugin to obtain WordPress administrator session cookies. On August 16, DigitalOcean reportedly blocked an anomalous administrator session originating outside its trusted network, and investigation traced the activity to exploitation against Standard edition version 16.1.9.

The active exploitation makes this more than an academic SAML implementation mistake. Patchstack has observed opportunistic scanning and exploit attempts from six IP addresses distributed across Europe, Africa and the United States. A proof-of-concept exploit targeting the free edition is also publicly available, which significantly lowers the barrier for additional attackers to begin scanning WordPress installations. Once a reliable PoC becomes public, exploitation tends to move from specialist researchers to commodity scanners with impressive speed, because apparently even cybercrime appreciates automation.

Another troubling aspect is the disclosure gap across miniOrange’s product editions. According to the reporting, the vendor’s public advisory initially covered only the free plugin even though the same underlying flaws affected six paid variants and fixes were released for them as well. Because WordPress administrators running paid versions were not necessarily shown ordinary dashboard update warnings, many site owners may have remained unaware that their deployments needed urgent updates. This created a period where fixes technically existed but customers could still remain exposed because the vulnerability information had not reached them clearly.

The patched versions vary by edition, which is important because administrators cannot simply look for “5.4.5” across every product. According to the current disclosure, the fixed releases are 5.4.5 for Free single-site, 13.0.4 for Premium single-site, 17.06 for Standard single-site, 20.2.8 for Premium/Enterprise/All-Inclusive multisite, 26.0.3 for Enterprise/All-Inclusive single-site, 32.0.8 for VIP single-site, and 35.0.7 for VIP multisite. Administrators need to identify exactly which edition is installed and verify against the corresponding fixed branch.

The immediate defensive action is therefore to upgrade to the appropriate patched version without waiting for an automatic WordPress notification. This point is especially important for paid editions, because Patchstack warns that those installations may not show the normal plugin update alert inside the WordPress administrator dashboard. Organisations should verify versions directly through the miniOrange plugin interface, deployment files or vendor portal rather than assuming that a quiet dashboard means there is nothing to update.

Patching should not be the only response for sites that were exposed while vulnerable, because these flaws allow full administrator authentication. Once an attacker obtains an administrator session, they can install plugins, modify themes, upload PHP files through legitimate WordPress functionality, create additional administrator accounts, modify existing accounts, change security settings or deploy persistent web shells. Updating miniOrange afterward prevents the same authentication bypass from being used again, but it does not remove any persistence established through the administrator access already obtained.

Administrators should therefore review WordPress user accounts for newly created administrators, unexpected changes to existing administrator email addresses, password modifications and unfamiliar application passwords. Any administrator identity that cannot be clearly attributed to a legitimate action should be investigated. If exploitation is suspected, all privileged WordPress sessions should be invalidated and administrator credentials changed from a trusted device.

Plugin and theme changes also deserve close examination. WordPress administrator access can be converted into remote code execution very easily because administrators can normally install or modify executable PHP content. Security teams should compare currently installed plugins and themes with a known-good inventory, inspect recent installation timestamps and look for unfamiliar PHP files in `wp-content/plugins`, `wp-content/themes`, `wp-content/uploads` and other writable directories. A small malicious plugin with an innocent-looking name can provide persistence long after the SAML vulnerability has been fixed.

File-integrity monitoring is particularly useful in this scenario. WordPress core files, plugin directories and theme files should be baselined, with alerts for unexpected additions or modifications. If the server does not normally permit direct code changes outside controlled deployment processes, any newly created PHP file following suspicious SAML activity should be treated as significant.

Web-server and WordPress logs should also be reviewed for abnormal SAML authentication activity. Administrators should search for bursts of requests to miniOrange SAML endpoints, login events associated with administrator identities from unfamiliar IP addresses, and SAML authentication events that do not correlate with successful logins recorded by the organisation’s actual identity provider. This last point is especially important. If WordPress shows that an administrator authenticated through SAML but Entra ID, Okta or another IdP has no corresponding successful authentication event, the mismatch can reveal forged SAML activity.

This cross-correlation between the service provider and identity provider is one of the strongest detection opportunities for attacks like this. SAML authentication relies on both systems agreeing that a login occurred. If the WordPress side believes a trusted identity assertion was received while the IdP has no record of issuing that assertion, something is clearly wrong. Security monitoring should therefore ingest both WordPress or miniOrange authentication logs and IdP logs where possible.

Administrators should also consider rotating SAML certificates and reviewing federation configuration if compromise is confirmed. The vulnerabilities do not inherently require theft of the legitimate IdP private key, so certificate rotation is not automatically necessary for every patched deployment. However, if an attacker obtained WordPress administrator or filesystem access, they may have been able to read SAML configuration, manipulate trust settings or install additional authentication mechanisms. In a confirmed compromise, federation settings should therefore be reviewed rather than assuming the problem ended at the plugin version.

A web application firewall can provide useful temporary protection against known exploit patterns, but it should not be relied upon as the primary control. The vulnerabilities occur in the interpretation and cryptographic validation of legitimate-looking SAML messages. Attackers can modify XML structure, encoding and signature content while preserving the underlying attack logic. The correct remediation is fixing the authentication implementation itself.

Restricting access to WordPress administration can reduce post-exploitation impact. Where operationally practical, `/wp-admin` and administrative functions should be limited to trusted networks, VPN users or managed devices. This will not necessarily prevent the initial forged SAML authentication if the SSO endpoint remains public, but it can create another boundary before the attacker gains full administrative functionality.

WordPress administrators should also enforce MFA for local privileged accounts, although this needs careful integration with SAML. MFA at the external IdP remains valuable, but these vulnerabilities demonstrate that downstream applications must still validate SAML assertions correctly. Strong MFA at Entra ID or Okta cannot protect an application that accepts an assertion the identity provider never issued. Authentication assurance is a chain, and every link has to verify the one before it.

The flaws provide an important lesson for application developers implementing SAML. The service provider should enforce a narrow allow-list of accepted signing algorithms, verify that the signature algorithm matches local configuration, reject deprecated algorithms, validate certificates against an explicitly trusted IdP, verify assertion issuer and audience, enforce timestamps and replay protections, and treat every cryptographic error as authentication failure. The incoming SAML document should never be allowed to redefine the security policy used to validate itself.

Algorithm confusion vulnerabilities such as CVE-2026-61979 are not unique to SAML. Similar classes of flaws have appeared in JWT implementations where applications accept an attacker-selected algorithm or confuse asymmetric and symmetric key types. The defensive principle is the same: algorithm selection belongs to the verifier’s trusted configuration, not to attacker-controlled input.

CVE-2026-15981 provides an equally durable coding lesson. Authentication code should use strict comparisons for cryptographic results and explicitly validate expected success values. Errors, exceptions and unexpected states should fail closed. A security function returning three possible states needs three deliberately handled outcomes; converting them casually into a boolean is how “verification error” becomes “welcome, administrator.”

Organisations operating multiple WordPress sites should use centralised plugin inventory and vulnerability management. miniOrange’s family spans seven editions with different release numbers, making manual tracking particularly error-prone. Security teams should be able to query which websites run miniOrange SAML SSO, which edition is installed and which version is currently active. Otherwise, every new plugin vulnerability becomes an archaeological exercise across forgotten websites.

This incident also reinforces the importance of keeping authentication plugins within formal change-management and security-review processes. WordPress plugins are sometimes treated as minor website extensions, but an SSO plugin effectively becomes part of the organisation’s identity infrastructure. Its code decides whether assertions from the corporate IdP are trustworthy and whether administrative access should be granted. That deserves substantially more scrutiny than an ordinary visual widget or content plugin.

For customers, the response should therefore be layered: identify every miniOrange SAML SSO deployment, determine the exact edition, upgrade to the corresponding fixed version, manually verify paid editions rather than relying on dashboard notifications, invalidate suspicious administrator sessions, review administrator accounts and plugin changes, inspect the filesystem for persistence, and correlate WordPress SAML logins with identity-provider authentication records. Sites exposed during the exploitation period should be treated as candidates for compromise assessment, not merely routine patching.

The broader lesson is that SSO reduces the number of passwords an organisation manages, but it also concentrates trust into the federation layer. When that layer validates a forged SAML response, the downstream application can be completely convinced that an attacker is a legitimate administrator even though the real identity provider never authenticated them. The password was not guessed, MFA was not defeated and the IdP itself was not compromised. The application simply accepted counterfeit proof of identity.

That is what makes CVE-2026-61979 and CVE-2026-15981 particularly dangerous. They attack the mechanism that tells WordPress whom to trust. Once attackers can manufacture their own trusted SAML assertions, every security decision based on that identity becomes unreliable. With active exploitation already observed and public proof-of-concept code available, administrators running any miniOrange SAML SSO edition should verify their version immediately and investigate whether unusual administrator sessions have already occurred.

Hackers are attempting to exploit two critical authentication bypass vulnerabilities in the miniOrange SAML 2.0 Single Sign On plugin for WordPress that can be used to forge SAML responses and log in as administrators. [...]

Source: Hackers target WordPress sites in miniOrange auth bypass attacks via Bleeping Computer — published 24 Aug 2026.