EUVD-2026-48429
GHSA-wgjx-q85h-87v2
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Remote, single unauthenticated request with no user interaction yields full admin account takeover, so AV:N/AC:L/PR:N/UI:N and C:H/I:H/A:H; scope unchanged within WordPress.
Primary rating from Vendor (Wordfence).
CVSS VectorVendor: Wordfence
Lifecycle Timeline
2DescriptionCVE.org
The SAML Single Sign On - SSO Login plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 5.4.4. This is due to the mo_saml_validate_signature() function performing a loose boolean check on the raw tri-state integer returned by PHP's openssl_verify(), causing an error return value of -1 to be evaluated as truthy and therefore treated as a successful signature verification. This makes it possible for unauthenticated attackers to log in as any existing WordPress user, including administrators, by submitting a crafted SAMLResponse containing an attacker-controlled NameID and a deliberately malformed signature value that triggers an OpenSSL processing error - bypassing verification entirely and resulting in wp_set_auth_cookie() being called for the targeted account.
Articles & Coverage 1
AnalysisAI
Authentication bypass in the miniOrange SAML Single Sign On - SSO Login plugin for WordPress (all versions through 5.4.4) lets unauthenticated attackers log in as any user, including administrators. The flaw stems from mo_saml_validate_signature() applying a loose boolean check to the tri-state integer returned by PHP's openssl_verify(), so the error value -1 is treated as truthy and accepted as a valid signature. Reported by Wordfence with a CVSS of 9.8; no public exploit has been identified at time of analysis, though the root cause and vulnerable code lines are publicly documented in the plugin source.
Technical ContextAI
The vulnerability lives in the plugin's SAML 2.0 response-handling stack (class-mo-saml-login-validate.php, class-mo-saml-utilities.php, and the bundled SAML2Core XML security library). PHP's openssl_verify() is explicitly tri-state: it returns 1 for a valid signature, 0 for an invalid signature, and -1 when an internal OpenSSL processing error occurs. Because the code evaluates the raw return value in a loose boolean context rather than strictly comparing to === 1, the -1 error state passes as success. This is a classic CWE-287 (Improper Authentication) failure driven by a signature-verification logic error: cryptographic verification is effectively skipped, so a SAML assertion's NameID is trusted without a validated signature. Affected package per CPE is cpe:2.3:a:cyberlord92:saml_single_sign_on_-_sso_login (the miniorange-saml-20-single-sign-on plugin).
RemediationAI
Update the plugin to the fixed release published in WordPress.org changeset 3611421 (https://plugins.trac.wordpress.org/changeset/3611421/miniorange-saml-20-single-sign-on); an upstream fix is available as a committed changeset, but a specific tagged patched version was not independently confirmed from the provided data, so verify the installed version is newer than 5.4.4 after updating. If you cannot patch immediately, deactivate the SAML SSO Login plugin to close the bypass entirely - the trade-off is that SAML-based login becomes unavailable and users must fall back to standard WordPress authentication. As an interim compensating control, restrict network access to the SAML assertion consumer/login endpoints (for example via WAF rules or IP allowlisting to trusted IdP egress addresses) so arbitrary unauthenticated SAMLResponse submissions are blocked; note this only works where the IdP has a stable, known source range. Review authentication logs and existing admin accounts for unexpected logins created via SAML, since the bypass leaves few other artifacts.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not pro
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today