CVE-2026-75807 in SAML Single Sign On Plugin
Summary
by MITRE • 08/29/2026
The SAML Single Sign On – SSO Login plugin for WordPress is vulnerable to Authentication Bypass in versions up to, and including, 5.4.6. This is due to the mo_saml_login_validate() ACS handler persisting the X.509 certificate extracted from an incoming SAMLResponse into the mo_saml_required_certificate option before the signature-validation verdict is enforced, because mo_saml_find_certificate() returns false on a fingerprint mismatch rather than halting execution. This makes it possible for unauthenticated attackers to overwrite the plugin's stored IdP signing certificate with an attacker-controlled value, and subsequently forge SAML assertions for any WordPress account — including administrators — to obtain a fully privileged session. Note: The exploit requires the administrator to perform a repair after receiving the test_config_error_wpsamlerr004 error message during the test configuration.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/29/2026
The vulnerability identified in versions up to and including 5.4.6 of the SAML Single Sign On – SSO Login plugin for WordPress represents a critical authentication bypass flaw rooted in improper certificate validation logic within the Assertion Consumer Service handler. This specific security defect allows unauthenticated attackers to manipulate the identity provider configuration, ultimately leading to full account compromise across all user roles, including administrators. The core technical issue lies in the execution flow of the mo_saml_login_validate function, which processes incoming SAML responses from external Identity Providers. In a secure implementation, certificate validation and signature verification must occur atomically or strictly before any state changes are persisted to the database. However, this plugin persists the X.509 certificate extracted from an incoming SAMLResponse into the mo_saml_required_certificate option prior to enforcing the final verdict on the digital signature validity. This temporal ordering error creates a race condition-like scenario where trust is established based on incomplete verification data rather than confirmed cryptographic integrity.
The mechanism of exploitation relies heavily on the behavior of the mo_saml_find_certificate function, which returns false when there is a fingerprint mismatch between the certificate presented in the SAML response and the one stored in the plugin's configuration. Crucially, this return value does not halt execution or trigger an immediate rejection of the request as expected in secure coding practices. Instead, the code proceeds to update the persistent storage with the new, potentially malicious certificate before checking if the signature validation actually succeeded. This design flaw means that even if the incoming SAML assertion is unsigned or signed with a key controlled by an attacker, the plugin will still accept and store the associated public key as the valid identity provider certificate for future validations. By overwriting the legitimate IdP signing certificate with one under their control, attackers effectively rewrite the trust anchor used to verify all subsequent login attempts.
Once this persistent state change is achieved, the operational impact is severe and immediate. The attacker can now forge SAML assertions signed with their own private key corresponding to the stored public key. Because the plugin trusts any assertion validated against the mo_saml_required_certificate option, these forged assertions are accepted as legitimate authentication events. This allows the unauthenticated actor to log in as any user account within the WordPress installation without possessing valid credentials or multi-factor tokens associated with those accounts. The ability to impersonate administrators grants complete control over the web application, enabling data exfiltration, defacement, malware injection, and further lateral movement into connected backend systems that rely on this WordPress instance for access management.
The exploit chain includes a specific prerequisite condition involving administrative interaction, which classifies this as an attack vector requiring limited initial access or social engineering rather than pure remote code execution without any user action. The attacker must first trigger the test_config_error_wpsamlerr004 error message during the plugin's configuration testing phase by sending malformed or mismatched SAML responses. This error prompts the administrator to perform a repair operation, which inadvertently executes the vulnerable certificate update logic described above. While this requirement for administrative interaction slightly raises the barrier to entry compared to fully automated remote exploits, it remains highly feasible in environments where administrators regularly test integration configurations with external identity providers. The reliance on user action does not mitigate the severity of the outcome but rather defines the attack surface as requiring a specific sequence of interactions between an attacker and a privileged user.
From a standards perspective, this vulnerability aligns closely with CWE-287 Improper Authentication, specifically involving misinterpretation of authentication state or failure to validate credentials before granting access. It also reflects aspects of CWE-913 Improvement of Control for Unnecessary Functionality, as the plugin performs certificate updates based on unverified input data during a configuration test rather than strictly validating cryptographic proofs first. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1078 Valid Accounts and potentially T1199 Trusted Relationship Exploitation if the attacker leverages the compromised trust relationship with an external IdP. The flaw demonstrates how improper handling of security-critical configuration data can undermine the entire authentication framework provided by SAML integration plugins.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary defense is to upgrade the plugin to a version greater than 5.4.6 where this logic error has been corrected, ensuring that certificate persistence occurs only after successful signature validation. Administrators should also audit their current configuration for any signs of unauthorized changes to IdP certificates if they have recently encountered test errors or suspicious login anomalies. For organizations unable to upgrade immediately due to compatibility constraints, disabling the automatic repair functionality during configuration tests may prevent accidental overwrites, though this is a temporary workaround rather than a fix. Developers should implement strict validation sequences where cryptographic checks are completed and verified before any state changes are committed to persistent storage. Additionally, implementing certificate pinning with explicit user confirmation for any changes to trust anchors can add an essential layer of defense against such manipulation attacks. Regular security audits of SAML integration code should prioritize the order of operations in authentication handlers to ensure that no side effects occur prior to final verification success.