Your scanner indicates that the plugin is already patched. There is no new update available according to the WordPress dashboard. The version of the software installed is way higher than the one indicated in the advisory. All three points have been in agreement with one another, and in fact, all three are wrong this month.
What is CVE-2026-61979? CVE-2026-61979 is a vulnerability that enables an unauthenticated attacker to bypass the authentication in the miniOrange SAML 2.0 Single Sign On plugin for WordPress with a CVSS score of 8.1. This vulnerability enables an unauthenticated attacker to bypass the authentication process by supplying a SAML response that signs into any user account, including administrator accounts.
Letting The Attacker Choose The Algorithm
It relies on one promise. The identity provider digitally signs the assertion using its private key and then the recipient application checks the signature against the corresponding public key. If this process fails, everything turns upside down.
The plugin reads the signature method from the incoming message instead of imposing the one it was supposed to use. The hacker simply changes the value of SignatureMethod to HMAC-SHA1 and thus forces the plugin to use symmetric instead of asymmetric signatures.
This change is absolutely devastating. In this case, the plugin interprets the RSA public key of the identity provider as the HMAC secret key. The public key is, by definition, publicly available from the metadata of the provider.
Therefore, the attacker retrieves the “secret”, produces an assertion himself and makes the plugin interpret it as authentic. As a result, the fraudulent assertion will contain an attacker’s chosen NameID and thus will belong to any user of the site.
When An Error Code Counts As Success
This one is easier and has a better CVSS score. CVE-2026-15981 has a CVSS score of 9.8.
The function openssl_verify() in PHP returns either 1, 0, or -1, depending on whether the signature is correct, incorrect, or when OpenSSL errors occur. The validation function for the plugin reduced this function to just a true/false condition.
In PHP, -1 is evaluated as true. If there is an input that causes OpenSSL to return an error, then this becomes a verification success.
How SAML Single Sign-On Works
Seven Editions Hiding Behind One Name
This is the part of the software which made the two vulnerabilities that could have been easily fixed a problem which caused the plugin to be exposed for weeks without any notification.
All versions of this software are packaged under the common WordPress slug miniorange-saml-20-single-sign-on. Nevertheless, the software has seven different independently versioned editions.
The free version has version numbers in the 5.x range, whereas standard and enterprise versions have 17.x and 26.x ranges respectively. The multi-site version has numbers above 35.x.
All seven versions were patched by miniOrange in July 2026. In the public notice, however, the vendor reported about the patched version only, that being 5.4.5. The patch was reported to be a bug fix and not a security fix.
Imagine the impact that such patch can have if run through the automated check. The question asked whether the installed version is higher than 5.4.5 and gets the answer of 16.1.9, which means that the patch was applied.
No prompts of updating the plugin appeared in the dashboard of paid versions because, in WordPress, updates cannot be prompted across the different major versions.
Scanning Began Before The Warnings Did
Opportunistic scanning is currently taking place from at least six different IP addresses located in Europe, Africa, and the US. A proof-of-concept implementation for the free version is openly available.
There is no effort made to determine the target’s edition through this scanning method. The attacker just makes the request on every website which has the slug and sees what answers. This version confusion that prevented the site from being alerted does not save it from being attacked.
We have covered this failure mode before, in a WordPress plugin flaw that let attackers register their own administrator accounts.
Access Control Failed First, Execution Comes Next
There are two separate issues raised by an attack like this, and confusing the two misses the point entirely.
One is the Zero Trust issue, who is authorized to access this resource. In this case, the answer came down to an invalid signature, meaning the identity could not be verified at all. It is too late for monitoring of the session afterwards to address the issue, since the session is already completely valid from start to finish.
The second issue comes right after the first, and it is a separate issue altogether. Administrators are an entry point into the system, not an end goal. What comes next is loading a plugin, uploading a web shell, or writing a file to the server, and these actions involve code being run somewhere.
Execution Governance process deals with the second issue directly. Instead of looking at whether the administrator’s actions were suspicious in nature, enforcement occurs at the kernel level and asks whether the code performing these actions is known to be valid. Code uploaded via a compromised administrative panel cannot be considered verified code, and it therefore runs in Kernel API Virtualization mode.
Conclusion: The Session Was Valid. The Identity Was Forged.
The defining lesson from the miniOrange SAML flaws is that an authentication system can produce a completely valid administrator session after making the wrong trust decision.
CVE-2026-61979 allowed attacker-controlled SAML input to influence the signature algorithm, creating a path where public key material could be misused to validate a forged assertion. CVE-2026-15981 reached the same outcome through a different verification failure, treating an OpenSSL error as success. In both cases, the attacker does not need the administrator’s password. The application accepts the assertion, maps it to an existing account, and creates a session that downstream WordPress controls can treat as legitimate.
The remediation problem makes this incident more consequential. Seven independently versioned editions exist under one plugin slug. A paid installation can therefore carry a numerically higher version than the publicly documented fixed free release while still belonging to a vulnerable edition line. When scanners, dashboards, and administrators reduce remediation to a simple version comparison, all three can agree that a system is safe and still be wrong.
Why This Threat Matters
- The cryptographic boundary is the authentication boundary. If assertion verification fails, the application can grant privileged access without the legitimate identity provider ever authenticating the attacker.
- MFA does not repair a forged assertion path. The vulnerable service provider accepts the result after the normal identity verification path has effectively been bypassed.
- A valid session can hide the original failure. Activity after login may look like ordinary administrator behavior because WordPress believes authentication already succeeded.
- Version numbers are not enough when editions diverge. Security teams need the correct edition-specific affected and fixed ranges, not a single comparison against the plugin slug.
- Silent fixes create remediation blind spots. A patched build provides little operational value if affected customers are not correctly identified and prompted to move to it.
- Administrator access is a pivot point. A forged privileged session can become more consequential if it is later used to alter plugins, write server-side files, or introduce executable code.
Where Defensive Control Must Operate
The first control point is accurate exposure and remediation state.
Xcitium Vulnerability Assessment helps identify vulnerable software, patch gaps, and configuration weaknesses, but this incident also demonstrates why asset context matters. Edition, installed release, affected range, and actual fixed version must be evaluated together rather than assuming a higher version number means remediation is complete.
If forged administrative access later becomes malicious plugin, web shell, or other untrusted code execution on a supported managed system, Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform adds a separate runtime boundary. Execution Governance governs what unknown code may do before trust exists, even when the action that introduced it originated from a session the application considered valid.
Patch the Edition, Not Just the Number
Organizations using miniOrange SAML should identify the exact edition installed, compare it against the corresponding fixed release, and verify remediation directly rather than relying only on dashboard status or a generic vulnerability range. Privileged sessions observed during the exposure window should also be reviewed for unexpected administrative changes.
The larger lesson extends beyond this plugin. Authentication succeeds only when the assertion deserves trust. A valid session created from a forged identity is not evidence that the security boundary worked.
