CVE-2026-63182 in LightSAML
Summary
by MITRE • 10/30/2026
LightSAML implements SAML 2.0 data model classes, XML serialization and deserialization, XML security, certificate support, and message bindings. Prior to 4.7.1 and 5.0.1, LightSAML and xmlseclibs disagree about which assertion an inbound SAML signature covers. `Response::deserialize` uses `manyElementsFromXml` to collect only direct-child `saml:Assertion` elements of `samlp:Response`, and `AssertionSignatureValidatorAction` validates their `ds:Signature` using an out-of-band trusted IdP credential resolved by Issuer, not a key from the document. `XMLSecurityDSig::validateReference()` removes the enveloped signature from the shared DOM, but `processRefNode()` resolves `Reference URI="#id"` document-wide through an XPath of the form `//*[@Id]` and takes `item(0)`, which need not be the assertion whose claims LightSAML consumes. An attacker who has captured one genuinely signed assertion, such as an earlier login response, can place its signature-stripped bytes earlier in `samlp:Extensions` and present a forged direct-child assertion with the same ID and copied genuine signature. Validation then covers the hidden genuine bytes while LightSAML surfaces unsigned attacker-controlled `Subject/NameID`, `Conditions`, and `Attributes`, enabling authentication bypass or privilege escalation even when signature validation is required. The behavior was confirmed in versions 5.0.0 and 4.6.1. This issue is fixed in versions 4.7.1 and 5.0.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability resides within the LightSAML library, a PHP implementation of the SAML 2.0 standard that handles data model classes, XML serialization, deserialization, and security operations including signature validation. The core flaw stems from a critical disagreement between LightSAML's parsing logic and the underlying xmlseclibs cryptographic library regarding which assertion an inbound digital signature is intended to cover. This discrepancy creates a significant authentication bypass risk by allowing attackers to decouple the verified integrity of a document from the actual data processed by the application. The issue affects versions prior to 4.7.1 and 5.0.1, where the parsing mechanism fails to ensure that the cryptographic signature validates against the specific XML element being consumed for security decisions.
During the processing of an inbound SAML Response, LightSAML utilizes a method called manyElementsFromXml to collect only direct-child saml:Assertion elements from the parent samlp:Response structure. This approach correctly isolates the assertions that will be used by the application logic. However, when the AssertionSignatureValidatorAction proceeds to validate these assertions using an out-of-band trusted Identity Provider credential resolved via the Issuer attribute, a conflict arises with how xmlseclibs handles XML Digital Signatures. Specifically, while XMLSecurityDSig::validateReference() removes the enveloped signature from the shared Document Object Model tree during validation, the subsequent processRefNode method resolves references using an XPath expression of the form //*[@Id]. This global search scope means that if multiple elements share the same Id attribute within the document, the library may select any matching element rather than strictly binding to the direct-child assertion being validated.
This technical flaw enables a sophisticated signature substitution attack where an attacker can manipulate the order and structure of XML nodes without breaking cryptographic verification. By capturing a legitimately signed SAML assertion from a previous login response, an adversary can strip its digital signature bytes and insert them earlier in the samlp:Extensions section or another part of the document that is not directly consumed by LightSAML for authentication decisions. The attacker then presents a forged direct-child assertion with the same Id attribute as the genuine one but containing maliciously crafted Subject/NameID, Conditions, and Attributes fields. Because xmlseclibs resolves the reference globally via XPath, it locates the hidden signature-stripped bytes from the original valid assertion and validates them successfully against the trusted key. Consequently, LightSAML accepts the response as cryptographically signed while simultaneously processing the unsigned, attacker-controlled data for identity resolution.
The operational impact of this vulnerability is severe, facilitating authentication bypass and privilege escalation in systems relying on SAML-based single sign-on mechanisms. An attacker can impersonate any user or elevate privileges by substituting the claims within an otherwise validly signed response envelope. This undermines the fundamental security guarantee of digital signatures, which is to ensure that data has not been altered since it was signed. The vulnerability aligns with CWE-345 Insufficient Verification of Data Authenticity and CWE-20 Improper Input Validation, as the application fails to correctly bind cryptographic verification to the specific input elements being processed. In terms of MITRE ATT&CK mapping, this behavior reflects techniques associated with T1610 Redundant Processing or potentially T1199 Trusted Relationship Abuse if exploited in a broader federation context, though it primarily represents a logic flaw in signature binding rather than external trust exploitation.
Mitigation for this vulnerability requires an immediate upgrade to LightSAML versions 4.7.1 and 5.0.1 or later, where the parsing and validation logic has been corrected to ensure that signatures are strictly bound to their intended target elements within the XML structure. Developers should also review any custom implementations of SAML processing to ensure they do not rely on global XPath searches for signature verification without explicit scoping to the specific node being validated. Implementing strict namespace-aware XPath queries and ensuring that validation occurs before or during the extraction of assertion data can further harden applications against similar structural manipulation attacks. Organizations relying on LightSAML should verify their dependency versions and apply patches promptly to prevent potential unauthorized access through signature substitution exploits.