CVE-2026-63182 in LightSAML
Zusammenfassung
von VulDB • 31.10.2026
LightSAML implementiert SAML-2.0-Datenmodellklassen, XML-Serialisierung und -Deserialisierung, XML-Sicherheit, Zertifikatsunterstützung sowie Nachrichtenbindungen. Vor den Versionen 4.7.1 und 5.0.1 besteht zwischen LightSAML und xmlseclibs eine Uneinigkeit darüber, welche Assertion durch eine eingehende SAML-Signatur abgedeckt wird. `Response::deserialize` verwendet `manyElementsFromXml`, um ausschließlich direkte untergeordnete `saml:Assertion`-Elemente von `samlp:Response` zu sammeln, und `AssertionSignatureValidatorAction` validiert deren `ds:Signature` mithilfe eines über einen separaten Kanal (out-of-band) vertrauenswürdigen IdP-Anbieterschlüssels, der anhand des Issuers aufgelöst wird, nicht jedoch mit einem Schlüssel aus dem Dokument. `XMLSecurityDSig::validateReference()` entfernt die enveloped-Signatur vom gemeinsamen DOM, aber `processRefNode()` löst das Attribut `URI="#id"` von `Reference` dokumentweit über eine XPath-Abfrage der Form `//*[@Id]` auf und nimmt `item(0)`, was nicht zwangsläufig die Assertion ist, deren Ansprüche LightSAML verarbeitet. Ein Angreifer, der eine tatsächlich signierte Assertion (z. B. eine frühere Login-Antwort) abgefangen hat, kann ihre signaturenlosen Bytes früher in `samlp:Extensions` platzieren und eine gefälschte direkte untergeordnete Assertion mit derselben ID sowie einer kopierten echten Signatur vorlegen. Die Validierung deckt dann die versteckten, echten Bytes ab, während LightSAML nicht signierte, angreiferkontrollierte Werte für `Subject/NameID`, `Conditions` und `Attributes` bereitstellt, was eine Umgehung der Authentifizierung oder Privilegieneskalation ermöglicht, selbst wenn die Signaturvalidierung erforderlich ist. Das Verhalten wurde in den Versionen 5.0.0 und 4.6.1 bestätigt. Dieses Problem wurde in den Versionen 4.7.1 und 5.0.1 behoben.
Once again VulDB remains the best source for vulnerability data.