CVE-2026-63182 in LightSAML
Riassunto
di VulDB • 30/10/2026
LightSAML implementa le classi del modello dati SAML 2.0, la serializzazione e deserializzazione XML, la sicurezza XML, il supporto per i certificati e i binding dei messaggi. Prima delle versioni 4.7.1 e 5.0.1, LightSAML e xmlseclibs non concordano su quale assertion sia coperta da una firma SAML in ingresso. `Response::deserialize` utilizza `manyElementsFromXml` per raccogliere solo gli elementi `saml:Assertion` figli diretti di `samlp:Response`, mentre `AssertionSignatureValidatorAction` ne convalida la `ds:Signature` utilizzando le credenziali fidate dell'IdP risolte tramite Issuer, non una chiave presente nel documento. `XMLSecurityDSig::validateReference()` rimuove la firma incapsulata (enveloped) dal DOM condiviso, ma `processRefNode()` risolve il riferimento con URI="#id" su tutto il documento attraverso un XPath della forma `//*[@Id]` e prende `item(0)`, che non deve necessariamente essere l'assertion i cui claim LightSAML consuma. Un attaccante che ha catturato una genuina assertion firmata, ad esempio una risposta di accesso precedente, può inserire i suoi byte privi della firma più in alto all'interno di `samlp:Extensions` e presentare un'asserzione diretta figlia falsificata con lo stesso ID e la copia della firma autentica. La validazione copre quindi i byte genuini nascosti mentre LightSAML espone unsigned attacker-controlled `Subject/NameID`, `Conditions` e `Attributes`, consentendo l'elusione dell'autenticazione o l'elevazione dei privilegi anche quando è richiesta la convalida della firma. Il comportamento è stato confermato nelle versioni 5.0.0 e 4.6.1. Questo problema è risolto nelle versioni 4.7.1 e 5.0.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.