CVE-2026-86304 in MojoX::Authentication
Summary
by MITRE • 09/07/2026
MojoX::Authentication versions before 0.006 for Perl allow SAML authentication bypass because parse_assertion builds Net::SAML2::Binding::POST without a trust anchor.
parse_assertion in MojoX::Authentication::Model::SAML2 calls Net::SAML2::Binding::POST->new with no cacert, cert_text or anchors argument, then passes the returned XML to Net::SAML2::Protocol::Assertion->new_from_xml with the IdP signing certificate as cacert. In Net::SAML2 before 0.86 that certificate guards only encrypted assertions, so the signature on an unencrypted assertion is checked against the certificate the response itself carries.
An attacker starts a SAML login, then posts a response signed with a certificate of their own. The audience, InResponseTo and timestamp checks that follow are all satisfiable by the attacker, so the response authenticates any NameID it carries.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability identified in MojoX::Authentication versions prior to 0.006 represents a critical authentication bypass within Perl-based web applications utilizing SAML for identity management. The core technical flaw resides in the parse_assertion method of the MojoX::Authentication::Model::SAML2 module, which fails to properly configure trust anchors when instantiating Net::SAML2::Binding::POST objects. Specifically, this instantiation occurs without providing a certificate authority file (cacert), specific certificate text, or explicit anchor configurations. This omission creates a gap in the cryptographic verification process that is exploited due to limitations present in older versions of the underlying Net::SAML2 library, specifically those before version 0.86. In these earlier iterations, the provision of an IdP signing certificate as a cacert parameter only applies validation logic to encrypted assertions. Consequently, for unencrypted assertions, which are common in many SAML deployments due to performance and complexity considerations, the signature verification relies on the certificate embedded within the response itself rather than a pre-configured trusted authority list.
This architectural weakness allows an attacker to perform a man-in-the-middle or replay-style attack where they intercept or forge a SAML authentication flow. By initiating a legitimate login sequence with a Service Provider and then submitting a forged SAML response, the attacker can sign their own assertion using a certificate under their control. Because the application does not enforce strict trust anchor validation for unencrypted assertions in this version range, it accepts the signature as valid if the embedded certificate matches certain loose criteria or if the library defaults to trusting the source of the XML data rather than verifying against a known Identity Provider public key. The subsequent checks performed by the framework, including audience restriction verification, InResponseTo correlation, and timestamp validation, are designed to prevent replay attacks but can be satisfied by an attacker who controls both the assertion content and its signing certificate within the context of this specific implementation flaw.
The operational impact of this vulnerability is severe, resulting in a complete bypass of authentication mechanisms. An adversary capable of exploiting this issue can authenticate as any user identity specified in the NameID field of the forged SAML response. This effectively grants unauthorized access to protected resources and sensitive data without valid credentials from the legitimate Identity Provider. The attack does not require breaking cryptographic algorithms but rather exploits the misconfiguration of trust validation logic, making it a straightforward exploitation vector for attackers with network-level access or those who can inject traffic into the authentication channel.
From a classification perspective, this vulnerability aligns with CWE-287, which describes Improper Authentication, specifically relating to the failure to verify identity claims against trusted sources. It also maps to MITRE ATT&CK technique T1651, Service Scripting, as it involves manipulating SAML protocol messages during an active session, and potentially T1098, Account Manipulation, if used to establish persistent unauthorized access by forging administrative identities. The root cause is a failure in cryptographic object initialization that leads to insufficient verification of digital signatures on unencrypted data streams.
To mitigate this vulnerability, organizations must upgrade MojoX::Authentication to version 0.006 or later, where the parse_assertion logic has been corrected to properly enforce trust anchor validation regardless of encryption status. Additionally, administrators should ensure that the underlying Net::SAML2 library is updated to version 0.86 or newer, which addresses the limitation regarding signature verification for unencrypted assertions by ensuring consistent application of certificate-based trust chains. As a defense-in-depth measure, security teams should enforce strict audience URI matching and validate InResponseTo fields against expected request IDs to limit the window of opportunity for replay attacks, although these controls are secondary to fixing the primary cryptographic validation flaw. Regular auditing of SAML configuration parameters is recommended to ensure that no legacy configurations bypass modern security standards for identity federation.