Security Brief: CVE-2026-15013 WordPress SAML SSO Flaw Enables Administrator Account Takeover
https://vulnify.app/blog/security-brief-cve-2026-15013-wordpress-saml-sso-authentication-bypass

CVE-2026-15013 is a critical authentication bypass in the SAML Single Sign On - SSO Login plugin for WordPress through version 5.4.3. The plugin can be tricked into validating an attacker-controlled SAML response with the wrong signature algorithm, allowing unauthenticated attackers to impersonate existing users, including administrators.

What happened CVE-2026-15013 is a critical authentication bypass vulnerability in the SAML Single Sign On - SSO Login plugin for WordPress, developed by miniOrange. The issue affects all versions through 5.4.3 and can allow an unauthenticated attacker to forge a SAML response that is accepted as valid. Wordfence assigns the vulnerability a CVSS 3.1 score of 9.8. The flaw is classified as improper verification of a cryptographic signature because the plugin can be persuaded to verify a SAML assertion using an attacker-selected signature algorithm rather than enforcing the locally trusted algorithm associated with the configured identity provider. Successful exploitation can allow an attacker to target any existing WordPress account, including an administrator. Once the forged SAML assertion is accepted, the plugin can issue normal WordPress authentication cookies for the impersonated user. The attacker then gains the permissions of that account without knowing its password. The vulnerability was reported by researcher lhking and publicly disclosed in July 2026. Version 5.4.4 addressed CVE-2026-15013 specifically, but the plugin subsequently received additional authentication-related security fixes. For current deployments, administrators should update to the latest vendor-supported release rather than stopping at the first version that fixed this individual CVE. How SAML authentication should work SAML single sign-on allows a WordPress site to rely on an external identity provider such as an enterprise identity platform. The identity provider authenticates the user and returns a signed SAML response containing identity information. The WordPress service provider verifies that response before creating a local session. The signature is the critical trust mechanism. The application should verify the SAML response using the identity provider's known public key and an approved signature algorithm. Values inside the SAML document are attacker-controlled until that verification succeeds. A secure flow is: User authenticates with trusted IdP | v IdP signs SAML assertion | v WordPress plugin receives SAMLResponse | v Plugin enforces configured algorithm and key | v Cryptographic signature is verified | v Identity claims are trusted | v WordPress session is created CVE-2026-15013 breaks the enforcement step. The plugin reads the signature algorithm declared inside the incoming SAML response and uses that value when deciding how to interpret the configured key material. Signature algorithm confusion The vulnerable function, Mo_SAML_Utilities::mo_saml_cast_key() , reads the SignatureMethod algorithm from the attacker-controlled SAML response. Instead of requiring the algorithm configured for the trusted identity provider, affected versions can recast an RSA public key for use in an HMAC-SHA1 verification path. RSA and HMAC use keys in fundamentally different ways. RSA verification uses a public key to verify a signature created with a corresponding private key. HMAC uses the same shared secret for generating and verifying a message authentication code. If an RSA public key is incorrectly treated as an HMAC shared secret, the public key is no longer secret. An attacker who knows the public key can calculate the HMAC value expected by the vulnerable verifier. This is a classic algorithm confusion problem: cryptographic material that is safe in one verification model becomes attacker-usable when the application accepts a different algorithm without enforcing policy. The high-level failure is: Attacker creates SAML response | v Response declares attacker-chosen SignatureMethod | v Plugin accepts algorithm from untrusted XML | v Trusted RSA public key is interpreted incorrectly | v Forged signature validates | v Attacker-selected account identity is accepted The vulnerability is not a weakness in SAML itself. It is a failure to bind the verification process to trusted local configuration. From forged SAML to WordPress takeover Once a forged assertion is accepted, the plugin can map the supplied identity to an existing WordPress user. According to the Wordfence advisory, this can include administrator accounts. The plugin then creates valid WordPress authentication cookies for that user. Administrator access can lead to complete application compromise because a WordPress administrator may be able to install plugins, edit site content, create users, change settings, and access sensitive data. On sites where plugin installation or file editing is allowed, administrator access can also become server-side code execution. The exact downstream impact depends on WordPress configuration, hosting restrictions, multisite settings, and whether administrative file modification has been disabled. Even where direct code execution is blocked, taking over an administrator account still provides extensive control over the site and its data. Affected versions and fix The CVE record identifies the affected range as all versions through 5.4.3: SAML Single Sign On - SSO Login 5.4.3 and earlier: AFFECTED Version 5.4.4: fixes CVE-2026-15013 specifically However, administrators should not interpret 5.4.4 as the preferred target today. A separate authentication bypass was later reported against 5.4.4, and the plugin has received subsequent security updates. As of September 2026, the public plugin listing shows a newer 5.4.7 release. The practical recommendation is therefore to install the latest supported version available from the official plugin distribution channel, currently 5.4.7 or later, rather than deliberately remaining on 5.4.4. Organizations using controlled enterprise change windows should also verify the identity-provider configuration after updating, because SSO plugins sit directly on the authentication boundary and deserve functional testing before and after a security upgrade. Why it matters for website owners SAML SSO is often deployed on business, education, government, membership, and enterprise WordPress sites specifically to centralize authentication. That makes a signature-verification failure especially important because it undermines the control intended to replace local passwords. The attack does not require a legitimate WordPress account. It targets the trust relationship between WordPress and the identity provider. If the plugin accepts a forged assertion, the strength of the user's real SSO password, multifactor authentication, or identity-provider session does not help because the attacker is bypassing the assertion-verification step. Organizations should also consider the privileges of the accounts mapped through SAML. Sites that allow administrator identities to authenticate through the affected plugin have the highest potential impact, but lower-privileged accounts may still expose private content or application functions. This vulnerability is a reminder that authentication plugins need the same patch priority as WordPress core. A fully updated CMS can still be compromised if the component that decides who is logged in accepts forged identity evidence. What to check on your site Identify the exact plugin. Confirm whether the miniOrange SAML Single Sign On - SSO Login plugin is installed on production, staging, or development WordPress sites. Check the installed version. Versions through 5.4.3 are affected by CVE-2026-15013. Update to the latest supported release rather than stopping at 5.4.4. Review SSO configuration. Confirm the expected identity provider, certificate, signature algorithm, issuer, and audience settings. Review administrator accounts. Identify privileged users that can authenticate through SAML and check for unexplained sessions or recent profile changes. Inspect authentication logs. Look for unusual SAML logins, impossible source locations, unexpected user agents, or sessions that do not correspond with identity-provider logs. Compare WordPress and IdP logs. A WordPress SSO session with no matching successful identity-provider authentication deserves investigation. Check for persistence. If unauthorized administrator access is suspected, review plugins, themes, must-use plugins, users, scheduled tasks, and modified PHP files. Invalidate sessions after compromise. If an account was impersonated, revoke WordPress sessions and follow the identity provider's incident procedures where appropriate. Recommended response Update the plugin to the latest supported release from the official source. If an update cannot be deployed promptly and SAML login is not essential, temporarily disabling the plugin or the affected SSO flow can reduce immediate exposure. Any temporary workaround should be tested carefully to avoid locking legitimate administrators out of the site. After patching, review authentication history. Because the flaw creates valid WordPress sessions, a successful attack may resemble an ordinary login unless logs from WordPress and the identity provider are compared. High-value sites should verify that privileged SSO sessions have a corresponding trusted IdP event. If unauthorized administrator access is found, assume the attacker could have changed the site beyond the authentication plugin. Restore modified application files from trusted sources, remove unknown users and plugins, rotate credentials exposed through WordPress, and review external integrations accessible from the administrator account. Secure SAML validation SAML implementations should treat algorithm identifiers, certificates embedded in messages, identity claims, relay state, and other response content as untrusted until the cryptographic signature has been validated against local policy. The service provider should know in advance which identity provider is trusted, which certificate or key belongs to that provider, and which signature algorithms are acceptable. Incoming SAML metadata should not be able to downgrade or reinterpret those requirements. Applications should also validate assertion conditions such as audience, issuer, destination, timestamps, and replay protections. Cryptographic signature verification is necessary, but it is only one part of complete SAML validation. Using Vulnify for WordPress review Vulnify's WordPress Stack Checker can help website owners identify publicly detectable WordPress technology and prioritize properties that need a direct plugin inventory. It does not authenticate to WordPress or verify internal SAML configuration. For a broader workflow, the WordPress Security Workflows documentation can help combine public-surface assessment with the internal checks required for plugins, accounts, and administrative settings. CVE-2026-15013 ultimately needs direct verification inside the WordPress environment. A public scan cannot determine whether the plugin enforces the correct SAML algorithm or whether a forged assertion was previously accepted. Related reading WordPress Stack Checker WordPress Security Workflows Conclusion CVE-2026-15013 is a critical authentication bypass in the SAML Single Sign On - SSO Login plugin for WordPress through version 5.4.3. The flaw allows attacker-controlled SAML metadata to influence the signature algorithm, creating an algorithm confusion condition that can make forged identity assertions appear valid. Successful exploitation can impersonate existing WordPress users, including administrators, without knowing their passwords. Version 5.4.4 fixed this specific CVE, but later security work means administrators should update to the current supported release rather than stopping at the minimum historical fix. Sites using SAML should review plugin versions, identity-provider configuration, privileged account activity, and the correlation between WordPress sessions and trusted IdP logs. SSO only strengthens authentication when every component in the assertion-validation chain enforces the same trusted cryptographic policy. Sources NIST NVD: CVE-2026-15013 Wordfence Intelligence: SAML Single Sign On Authentication Bypass