CVE-2026-15013: miniOrange WordPress SAML SSO Bypass
TL;DR - Critical auth bypass in miniOrange SAML Single Sign On plugin for WordPress. - Affects versions up to and including 5.4.3; upgrade to 5.4.4 or later. - Treat as urgent because unauthenticated attackers may forge SAML logins as admins.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-15013 |
| CVSS | 9.8 Critical |
| Attack vector | Network |
| Privileges required | None |
| Patch available | Yes, upgrade to 5.4.4 or later |
This issue affects the miniOrange SAML Single Sign On – SSO Login WordPress plugin, plugin slug miniorange-saml-20-single-sign-on. According to the NVD description, the bug allows an unauthenticated attacker to forge a SAML assertion for any existing WordPress user, including administrators, which can result in full administrator-level account takeover.
For defenders, the key operational point is that this is not a nuisance bug or partial privilege issue. It is a trust-boundary failure in the SSO path itself. Any internet-exposed WordPress site using the vulnerable plugin versions should be considered at high risk until upgraded and reviewed for suspicious SAML-based logins.
What Is This Vulnerability?
CVE-2026-15013 is an authentication bypass caused by SAML signature algorithm confusion. Per NVD, the plugin reads the SignatureMethod algorithm value from the attacker-controlled SAMLResponse parameter rather than enforcing the locally configured or otherwise trusted algorithm expected for the Identity Provider. That behavior lets an attacker influence how the plugin interprets the signature validation process.
The reported impact is severe because the plugin can end up treating the IdP’s RSA public key as if it were an HMAC-SHA1 shared secret. In practice, that breaks the intended asymmetric trust model of SAML signature verification. Once the verification logic accepts a forged assertion, an attacker can impersonate any WordPress account named in the assertion, obtain valid authentication cookies, and log in as that user.
This is the sort of bug that collapses the security assumptions behind SSO. Defenders should not think of it as just “bad input validation.” It is a core authentication design failure in the plugin’s SAML processing flow, and that is why the score is near maximum severity.
Technical Notes
The NVD references point to these code locations in the WordPress plugin repository browser:
class-mo-saml-login-validate.phpclass-mo-saml-utilities.phpincludes/lib/SAML2Core/class-mo-saml-xml-security-key.php
The environment used for research could not directly fetch the referenced source pages because of 403 Forbidden, so line-by-line excerpts were not verified here. However, the NVD description specifically names Mo_SAML_Utilities::mo_saml_cast_key() as part of the vulnerable flow, which is the most important root-cause detail defenders need.
Who Is Affected?
The affected product is the miniOrange SAML Single Sign On – SSO Login plugin for WordPress. The vulnerable range, based on the NVD description, is all versions up to and including 5.4.3. That means 5.4.3 is vulnerable, and earlier releases should also be considered vulnerable.
The next observed release on WordPress.org is 5.4.4. While the research note did not include a vendor advisory explicitly saying “fixed in 5.4.4,” WordPress.org lists 5.4.4 as the current release, and it follows immediately after the vulnerable range ending at 5.4.3. For operational decision-making, defenders should treat 5.4.4 as the fixed version and upgrade there or later.
Affected organizations are those running WordPress sites that rely on this plugin for SAML SSO. That can include enterprise intranets, partner portals, customer-facing support sites, and smaller business sites that delegated identity to an external IdP. Any site where WordPress administrator accounts authenticate via this plugin is especially exposed because compromise of one admin-level session is enough to modify content, install code, or create persistence.
Technical Notes
To confirm whether a site uses the plugin, check the installed plugin list from WordPress or the filesystem:
wp plugin list | grep miniorange-saml-20-single-sign-on
Or inspect the plugin directory directly:
ls -la wp-content/plugins/miniorange-saml-20-single-sign-on
To check the installed version:
wp plugin get miniorange-saml-20-single-sign-on --fields=name,version,status
If WP-CLI is not available, inspect the plugin header in the main plugin file or review the WordPress admin Plugins page.
CVSS Score Breakdown
NVD assigns CVSS v3.1 9.8 Critical. The research note states that the exact vector string was not explicitly returned by the tool output, but the score is consistent with a vector such as AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Because the vector was not directly confirmed in the retrieved output, defenders should treat the score as authoritative and the vector explanation as a reasoned interpretation, not a quoted NVD vector string.
The score makes sense technically. Attack Vector: Network fits because exploitation occurs through a remote SAML login flow. Privileges Required: None fits because the attacker does not need an existing WordPress or IdP account on the target site if they can forge the assertion. User Interaction: None is also consistent because no administrator has to click anything. The expected impact on Confidentiality, Integrity, and Availability is high because administrator takeover can expose data, alter site code or configuration, and disrupt services.
For practitioners, the takeaway is simple: a 9.8 auth bypass in an internet-facing authentication component deserves emergency handling even when active exploitation has not yet been publicly confirmed. The combination of low complexity and high impact means risk can escalate quickly once attacker tradecraft matures.
Exploitation Status
At the time of this writing, CISA KEV status is false, meaning CVE-2026-15013 is not listed in the Known Exploited Vulnerabilities catalog. That matters because KEV inclusion is one of the stronger public signals of observed real-world exploitation against victims.
The current evidence set also indicates no confirmed public proof of concept was found in the retrieved research, and no primary-source confirmation of active in-the-wild exploitation was identified. A Wordfence threat intelligence result appears to track the issue and matches the vulnerability description, but that is secondary corroboration, not proof of exploitation.
Defenders should be careful not to over-read the lack of a public PoC. For SSO flaws, working exploit development is often straightforward for capable attackers once the root cause is understood. In the absence of exploitation confirmation, the right assumption is not “safe until proven otherwise.” The better assumption is “highly attractive target, likely to be weaponized.”
Technical Notes
What is known:
- PoC public? No confirmed public PoC located in the retrieved sources.
- Active exploitation confirmed? No primary-source confirmation found.
- KEV listed? No.
What defenders should assume in the absence of data:
- Internet-exposed WordPress SSO endpoints are likely to be scanned.
- Any unexplained admin login via SAML after public disclosure should be treated as suspicious.
- Post-authentication changes such as new admin users, plugin installs, or theme edits may indicate successful exploitation.
How to Detect It
Detection should focus on the SAML login flow, unusual authentication patterns, and the follow-on actions an attacker would take after obtaining administrator access. Because the described exploitation path involves a forged SAMLResponse, start by reviewing web server and application logs for requests hitting the plugin’s SSO endpoints, especially where admin sessions appear without expected IdP-side context or outside normal user timing patterns.
You should also look for anomalies in WordPress authentication events: administrator logins from unfamiliar IPs, new admin users, plugin or theme changes, unexpected session creation, and configuration changes soon after a SAML login. If your IdP logs show no corresponding successful authentication for a user that WordPress accepted, that discrepancy is a high-value indicator.
Technical Notes
Example web log hunting patterns for POSTs containing a SAML response:
grep -R 'SAMLResponse' /var/log/nginx /var/log/apache2 2>/dev/null
Look for suspicious requests to WordPress login or plugin-specific SSO handlers. A generic pattern to search:
grep -R -E 'POST .*wp-login|POST .*saml|SAMLResponse=' /var/log/nginx /var/log/apache2 2>/dev/null
Simple Splunk example for web logs:
index=web (uri_path="*saml*" OR uri_path="*wp-login.php*") ("SAMLResponse" OR method=POST)
| stats count values(src_ip) values(user_agent) values(uri_path) by host, status
Elastic / Kibana KQL example:
http.request.method: "POST" and url.path: (*saml* or *wp-login.php*) and message: "SAMLResponse"
WordPress follow-on checks for suspicious admin activity:
wp user list --role=administrator
wp plugin list
wp theme list
Review for recently added administrator accounts and unexpected plugin installations. If you have database audit visibility, investigate changes to wp_users, wp_usermeta, and option values related to plugin activation or authentication configuration.
Mitigation and Patching
The primary remediation is to upgrade the miniOrange SAML Single Sign On – SSO Login plugin to 5.4.4 or later immediately. Based on the available evidence, versions up to and including 5.4.3 are affected, and 5.4.4 is the next release listed on WordPress.org. If your change process normally batches plugin updates, this is the kind of issue that justifies an out-of-band exception.
If immediate patching is not possible, reduce exposure by disabling the plugin or temporarily disabling SAML SSO for WordPress until the update is complete. That is operationally disruptive, but it is safer than leaving a critical unauthenticated admin-takeover path exposed. Also invalidate active sessions, especially administrator sessions, if compromise is suspected. Then audit for persistence such as rogue admin users, modified theme files, new plugins, or suspicious cron jobs.
Technical Notes
Upgrade with WP-CLI:
wp plugin update miniorange-saml-20-single-sign-on --version=5.4.4
If you simply want the latest available secure release:
wp plugin update miniorange-saml-20-single-sign-on
Temporary workaround by deactivating the plugin:
wp plugin deactivate miniorange-saml-20-single-sign-on
If compromise is suspected, force session invalidation and rotate credentials as appropriate. At minimum, reset WordPress administrator passwords and review authentication cookies. You should also inspect for unauthorized changes:
wp user list --role=administrator
wp plugin list --status=active
wp theme list
If you cannot verify whether 5.4.4 is already installed across a fleet, inventory with WP-CLI or your configuration management tooling and prioritize all instances at 5.4.3 or below.
References
The primary reference for the vulnerability description is the NVD record for CVE-2026-15013. It provides the critical severity rating and the detailed explanation of the SAML signature algorithm confusion issue, including the attacker-controlled SAMLResponse behavior and account takeover outcome.
The WordPress.org plugin listing is the best available source in this research set for product identification and current version verification. Additional NVD-linked WordPress Trac references indicate the relevant code paths, although the source pages were not directly retrievable in the research environment. Secondary corroboration from Wordfence aligns with the NVD description.
- NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2026-15013
- WordPress.org plugin page: https://wordpress.org/plugins/miniorange-saml-20-single-sign-on/
- WordPress.org plugin page, markdown output: https://wordpress.org/plugins/miniorange-saml-20-single-sign-on/?output_format=md
- miniOrange plugin changelog: https://plugins.miniorange.com/wordpress-saml-single-sign-on-sso-plugin-changelog
- WordPress Trac reference: https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/class-mo-saml-login-validate.php#L119
- WordPress Trac reference: https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/class-mo-saml-utilities.php#L416
- WordPress Trac reference: https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/class-mo-saml-utilities.php#L444
- WordPress Trac reference: https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/class-mo-saml-utilities.php#L561
- WordPress Trac reference: https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/includes/lib/SAML2Core/class-mo-saml-xml-security-key.php#L722
- Secondary corroboration: https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/miniorange-saml-20-single-sign-on-2
For more information on related vulnerabilities, you may also want to check out our articles on what is malvertising and SAST (Static Application Security Testing).
If you are writing internal response guidance, the practical message is clear: identify any WordPress site using miniOrange SAML SSO, upgrade from 5.4.3 or earlier to 5.4.4 or later, and review recent SAML-driven admin activity for signs of compromise.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.