MojoX::Authentication CVE-2026-86304

Exploitation requires that the target web application uses MojoX::Authentication (before 0.006) as a SAML 2.0 service provider and accepts UNENCRYPTED assertions - the flaw is in the unencrypted-assertion signature path, so IdP-encrypted assertions are not bypassable this way. The attacker must be able to reach the SP's assertion consumer (POST binding) endpoint over the network and must initiate a legitimate SAML login to obtain a valid InResponseTo/session correlation value; no credentials or prior authentication are needed (PR:N). Limiting factors: the deployment must not enforce assertion encryption, must run the vulnerable module/Net::SAML2 (<0.86) versions, and the attacker needs to know or guess a valid target NameID; the audience and timestamp checks impose no real barrier as they are attacker-controllable.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8) is largely justified for confidentiality and integrity: a remote, unauthenticated attacker who can reach the SP login endpoint can forge assertions and log in as any NameID, including administrative accounts, which is a full authentication bypass. The A:H component is arguably overstated since the direct technical impact is impersonation rather than service disruption. Countervailing signals temper urgency somewhat: EPSS is only 0.11% (1st percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, and the affected component is an obscure CPAN module with a small deployment footprint, so mass exploitation is unlikely. That said, the exploit technique is well understood and mechanically simple, so any organization actually running MojoX::Authentication as a SAML SP - from a large enterprise down to a small municipal IT team in rybnik - should patch promptly, because the barrier to exploitation for anyone who targets them is low. Note the input tag 'Jwt Attack' is inaccurate; this is a SAML/XML-DSig flaw, not a JWT issue.

An attacker browses to a web application that uses MojoX::Authentication as its SAML SP and initiates a normal login, obtaining a valid AuthnRequest/InResponseTo value. They then craft a SAML response asserting a NameID of the victim (e.g., an administrator), sign it with a self-generated certificate embedded in the response, and POST it to the assertion consumer service; the SP validates the signature against the attacker's own certificate and grants an authenticated session as the chosen user. No public POC is identified at time of analysis, but the attack requires only standard SAML tooling.