SURIQ
The patch shipped over a week ago. That stopped protecting anyone who has not installed it, because a working exploit for the flaw went public today.
The bug, tracked as CVE-2026-15981, sits in miniOrange's SAML Single Sign On (SSO Login) plugin for WordPress, which runs on more than 10,000 sites. It lets an unauthenticated attacker log in as any existing WordPress user, administrators included, without a password. Wordfence, which assigned the CVE, rates it 9.8 out of 10. The fix is version 5.4.5. Anything up to and including 5.4.4 is exposed.
The second critical login bypass in this plugin in eight days
This is not the plugin's first bad week. On July 15 a separate critical authentication bypass in the same plugin, CVE-2026-15013, was disclosed and fixed in 5.4.4, according to WPScan's records. Two days later, 5.4.5 landed to close the one we are talking about here. The CVE record went public on July 23. A proof-of-concept exploit appeared on GitHub on July 26.
The window between those dates is the story. The fix has been sitting in the plugin repository for over a week while some share of the install base stayed on a vulnerable build. Now anyone can grab a ready-made exploit and skip straight to the payoff.
How a malformed signature turns into an admin login
SAML single sign-on works by trusting a signed assertion from an identity provider, the system that vouches for who you are. The plugin's job is to verify that signature before it logs anyone in. In the affected versions, that check was wrong in a way that is easy to describe and easy to abuse.
PHP's openssl_verify() returns one of three values: 1 for a valid signature, 0 for an invalid one, and -1 when the verification itself errors out. The plugin's mo_saml_validate_signature() function treated the outcome as a plain yes or no. A -1 is not zero, so a loose truthy test reads the error as success. An attacker sends a SAMLResponse that names whichever account they want to become in the NameID field, paired with a signature crafted so the verification errors instead of cleanly failing. The error is accepted as a valid signature, and the login proceeds. No credentials, no user interaction, no real identity provider involved.
The fix requires the result to be exactly 1 and treats every other value, error included, as a failed signature. That is the whole correction, and it is a reminder of how thin the margin can be between a working trust boundary and an open door.
Who should treat this as urgent
Any WordPress site running the plugin at 5.4.4 or earlier. The population that matters most is the one that installed a SAML SSO plugin in the first place: organizations wiring WordPress into Okta, Entra ID, Google Workspace, Keycloak, or another corporate identity provider. Those are the sites where a WordPress admin account is a foothold into something larger, and they are exactly the sites this plugin serves.
Full administrator control of WordPress is not a contained problem. From there an attacker can install a malicious plugin or theme, drop a web shell, mint new admin accounts, and pivot. A password reset does not evict them, because they never needed a password. We have watched the same takeover pattern play out through other WordPress plugins that handed attackers admin accounts.
How to tell if you were already hit
The exploit produces a successful WordPress login for a privileged account with no matching event on the identity provider side. That mismatch is the cleanest signal you have. If your identity provider has no record of issuing an assertion for a login that WordPress accepted, treat it as suspect.
On a site that ran a vulnerable version, look for:
-
Administrator or editor logins that do not line up with a real single sign-on event in your identity provider's logs.
-
New administrator accounts, or role changes to existing ones, that nobody on your team made.
-
Recently added or modified plugins and themes, and any unfamiliar PHP files under the web root.
-
Scheduled tasks (WP-Cron jobs) or outbound connections that no legitimate change explains.
This is the gap patching alone leaves open. Updating the plugin closes the hole; it says nothing about whether someone walked through it during the exposure window. Continuous monitoring of authentication events and file integrity on the host, rather than a one-time version scan, is what turns "we patched" into "we know we were not hit." Signature verification has been a soft spot across SAML implementations, from framework libraries to forged logins against Oracle WebLogic.
What to do now
-
Update the plugin to 5.4.5 or later today. This is the fix, and nothing else fully closes the hole.
-
If you cannot update immediately, disable the plugin. Losing SSO login for a while beats leaving an admin bypass open with a public exploit in circulation.
-
After patching, hunt. Assume the exposure window was live and run the checks above before you call it done.
-
Rotate what a rogue admin could have taken: other administrator credentials, API keys stored in the site, and any secrets reachable from the WordPress host.
Two critical authentication bypasses in one sign-on plugin inside eight days is a pattern worth naming. Getting the return-value handling of a signature check wrong is a classic mistake, and it keeps recurring across SAML code. If you rely on a plugin to broker trust between WordPress and your identity provider, its update cadence is part of your attack surface, not an afterthought.