Critical flaw in the WordPress plugin miniOrange SAML SSO (CVE-2026-15013): admin takeover with no password — update to 5.4.4
A critical flaw, CVE-2026-15013, was found in the WordPress SSO plugin 'SAML Single Sign On – SSO Login' (miniOrange). An attacker with no password could bypass signature verification, impersonate an administrator, and take over the site. Severity is CVSS 9.8, with 10,000+ installs. We cover updating to 5.4.4 and how to check for compromise.
Table of contents
A critical flaw, CVE-2026-15013, was found in the WordPress SSO plugin 'SAML Single Sign On – SSO Login' (miniOrange). An attacker with no password could bypass signature verification, impersonate an administrator, and take over the site. Severity is CVSS 9.8, with 10,000+ installs. We cover updating to 5.4.4 and how to check for compromise.
A near-top-severity flaw has been found in "SAML Single Sign On – SSO Login" (by miniOrange), a popular WordPress plugin used to consolidate logins for corporate and internal systems. An attacker who knows no password at all could impersonate an administrator account and take over the entire site. The U.S. NVD (CVE-2026-15013) published it on July 16, 2026. The severity is 9.8 out of 10 on the CVSS scale (Critical).
The plugin is installed on more than 10,000 sites worldwide. A fixed version 5.4.4 is already available, so if you run an affected version (5.4.3 or earlier), update immediately. This article walks through what happens, how to check whether your site is affected, and the steps to update and check for compromise.
What the plugin does, and why it's dangerous
"SAML Single Sign On – SSO Login" adds "single sign-on (SSO)" to a WordPress site. SSO is a mechanism that lets you log in once and then use multiple services in succession. It connects to corporate authentication services such as Microsoft (Entra ID / Azure AD), Google, Okta, and Keycloak, so employees can log in to WordPress with the accounts they already use. It is common on corporate intranets and membership sites.
This connection uses a standard called "SAML." SAML uses a digital signature to prove that a login is valid. The authentication service (the identity provider, or IdP) attaches a signature to a certificate saying "this person is who they claim to be," and the WordPress side verifies that signature to decide it is "certainly a legitimate login." If there is a gap in that signature check, a fake login can be mistaken for a real one. This flaw breaks exactly that verification. Because the mechanism guarding the very entrance is bypassed, the damage leads directly to "full takeover of the site."
What happens: inside the flaw
When exploited, an attacker who holds neither the password nor the account details can fake "authenticated" status without a legitimate signature and log in as any account, including an administrator. Here is an overview.
| Item | Details |
|---|---|
| Affected plugin | SAML Single Sign On – SSO Login (miniOrange) |
| Sites installed | 10,000+ |
| Severity | Critical (CVSS 9.8) |
| Precondition | None (any pre-auth outsider) |
| Affected versions | 5.4.3 and earlier (all) |
| Fixed in | 5.4.4 |
| Real-world abuse | None observed |
CVE-2026-15013: letting the attacker choose how the signature is verified
CVE-2026-15013 is classified as improper verification of a cryptographic signature (CWE-347). The WordPress side should verify the signature using a method set in advance, but the plugin's internal handling (a part called mo_saml_cast_key) reads which method to use from the contents of the login response the attacker sends. Worse, where it should verify with a secret key that only the real party holds, it reuses publicly available information as the verification key. As a result, an attacker can assemble a "forged signed login" that passes verification without holding a legitimate signature. It is rated CVSS 9.8 (Critical) because it lets an attacker seize administrator privileges with no authentication. The technical mechanism is explained below.
Who can take over
What makes this flaw frightening is how low the bar for attack is. Here is who can abuse it and how.
The people who can exploit it are any pre-authentication outsider who can reach the target site's login page (the attacker). No sign-up and no password are needed; they only need to be able to reach the login screen from the internet.
Using this hole, an attacker crafts a response disguised as a "legitimate login" without a real signature, and logs in to WordPress impersonating an administrator. Once in as an admin, they can do almost anything on the site: tamper with posts and pages, install malicious plugins or code, siphon off member data, and manipulate other user accounts.
For the company or organization running the site, the damage means "you thought you locked the entrance, but someone walked into the control room without a key." For members and employees using the site, it can lead to leaks of personal data or secondary damage from a hijacked site being used as a stepping stone. No real-world attacks have been reported yet, but once a fix ships, attackers are fast to reverse-engineer the method from the changes, so updating quickly is essential.
Is your site affected?
Affected sites are those running version 5.4.3 or earlier of this plugin — effectively every version released before the fix. To check whether you have the plugin, look for "SAML Single Sign On – SSO Login" in the WordPress admin under "Plugins." The version appears on the same screen.
| Situation | Impact | What to do |
|---|---|---|
| 5.4.4 or later | Not affected (fixed) | Nothing needed |
| 5.4.3 or earlier (all versions) | Affected (takeover possible) | Update to 5.4.4 now |
| Plugin not used | Not affected | Nothing needed |
Note that miniOrange offers several SSO-related plugins for WordPress. The target here is specifically the free "SAML Single Sign On – SSO Login." If you use a differently named SSO plugin, take this opportunity to confirm each is on its latest version.
The fix: update to 5.4.4 immediately
The fix is to update the plugin to 5.4.4 or later. The steps are as follows.
- Open "Plugins" → "Installed Plugins" in the WordPress admin
- If an update notice appears for "SAML Single Sign On – SSO Login," click "Update"
- After updating, confirm the version shows 5.4.4 or later in the plugin list
- If you cannot update right away, consider temporarily deactivating the plugin to stop SSO logins (after securing an alternate login method for your team)
If you manage many sites, run a bulk update through your management tool and then confirm each site's version actually moved up. Because this update touches the core of authentication, it is safest to also test that legitimate SSO logins still work after updating.
How to check whether you've been compromised
For flaws that bypass authentication, it is important not only to update but also to check whether you have already been breached. Especially for sites that have been live for a while, or whose login screen is broadly exposed to the internet, review the following.
- Any unfamiliar administrator accounts? Review every admin-level account in the "Users" list one by one
- Any unrecognized plugins or themes added? A rogue plugin installed without your knowledge may be used as a backdoor
- Any suspicious access in recent login history? Check a login-logging plugin or your server's access logs
- Have posts, pages, or theme files been tampered with? Look for suspicious links or scripts embedded in them
If you find anything suspicious, consider resetting all users' passwords and login secret keys, removing rogue accounts and files, and restoring from backup. Keeping a record of your review helps, since it can reveal whether an attack actually occurred. Whether a given flaw is "being actively exploited" is published in the U.S. CISA catalog; the official CISA Known Exploited Vulnerabilities catalog is a good place to check.
A technical look: why it could be bypassed
In SAML signature verification, the authentication service (IdP) normally signs with a "private key" that only it holds, and the WordPress side verifies with the matching "public key." Because only the IdP has the private key, only the IdP can produce a legitimate signature — that is the security premise.
But in this plugin, the mo_saml_cast_key handling reads which signature method to use from the algorithm name written in the incoming login response — data the attacker can supply. If the attacker specifies "HMAC-SHA1," things change. HMAC-SHA1 uses the same "shared secret" for both signing and verifying. In that case, the plugin uses the IdP's public key — which is meant to be public information — directly as the shared secret.
A public key is, by definition, public and available to anyone. So an attacker can compute a "valid signature" with HMAC-SHA1 using the public key as the secret, and attach it to a forged response that says "logged in successfully as administrator." Because the WordPress side verifies with the same public key, it accepts this forged signature as genuine. This is the classic and dangerous technique known as algorithm (or key) confusion: letting the attacker choose the verification method and swapping an asymmetric signature for a symmetric one. The fixed 5.4.4 stops reading the verification method from the response and instead verifies correctly according to the site's own configuration.
Severity and exploitation status
The severity is 9.8 on CVSS, classed as "Critical" out of 10. It requires no authentication, has a low attack difficulty, and, if successful, hands over full administrator privileges — hence a near-top rating. Because this plugin handles the login entrance itself, the flaw's impact reaches the whole site.
At the same time, no sign of real-world attacks has been observed, and it is not on the U.S. CISA list of vulnerabilities being actively exploited ("KEV"). Still, because a fix is already public, the chance rises that attackers reverse-engineer the method from the patch and attempt exploitation. "No abuse observed" does not mean "safe." Treat it as a high-urgency flaw and update as soon as you confirm it. This kind of "weak signature verification" shares a weakness with the recently disclosed signature forgery in the node-forge crypto library, an approach that has repeatedly targeted the foundations of authentication in recent years.
Frequently asked questions
Q. Am I at risk even if I don't use SSO?
A. Simply having this plugin active is the problem. Even if you don't use SSO heavily, you are affected if 5.4.3 or earlier is active. If you don't use it, update it, or deactivate and remove it.
Q. I can't update right away. What should I prioritize?
A. Because this is an urgent authentication-bypass flaw, updating is the top priority. If that is truly not possible, consider temporarily deactivating the plugin to stop SSO logins. Also check whether any unfamiliar administrator accounts have appeared.
Q. If I've already been breached, does updating make me safe?
A. Updating prevents "further" intrusion, but any rogue accounts already created or backdoors already planted remain. In addition to updating, be sure to run the checks in this article's "How to check whether you've been compromised" section.
Q. Are the paid version and other SSO plugins affected?
A. The target here is the free "SAML Single Sign On – SSO Login" (5.4.3 or earlier). That said, SSO and login-integration plugins are attractive targets, so keep every one of them on the latest version regardless of type.
Summary
A critical flaw, CVE-2026-15013, was found in the WordPress single sign-on plugin "SAML Single Sign On – SSO Login." An attacker with no password could slip past signature verification, impersonate an administrator, and take over the site. The severity is CVSS 9.8, a near-worst combination of no authentication and administrator takeover. The plugin is installed on more than 10,000 sites.
What to do is to update the plugin to the fixed 5.4.4 or later immediately. No real-world abuse has been observed yet, but attackers are fast to work out the method after a fix ships, so assume there is no grace period. Beyond updating, don't forget to check whether you've already been breached — starting with whether any unfamiliar administrator accounts exist.
Sources

Makoto Horikawa
Backend Engineer / AWS / Django