CVE-2026-63182 in LightSAML
Résumé
par VulDB • 31/10/2026
LightSAML implémente les classes du modèle de données SAML 2.0, la sérialisation et la désérialisation XML, la sécurité XML, le support des certificats et les liaisons de messages. Avant les versions 4.7.1 et 5.0.1, LightSAML et xmlseclibs sont en désaccord quant à l'assertion couverte par une signature SAML entrante. `Response::deserialize` utilise `manyElementsFromXml` pour collecter uniquement les éléments enfants directs `saml:Assertion` de `samlp:Response`, et `AssertionSignatureValidatorAction` valide leur `ds:Signature` en utilisant des identifiants d'IdP (Identity Provider) fiables résolus hors bande par l'émetteur, plutôt qu'une clé issue du document. `XMLSecurityDSig::validateReference()` supprime la signature enveloppée du DOM partagé, mais `processRefNode()` résout le URI de référence `#id` à l'échelle du document via une XPath de forme `//*[@Id]` et prend `item(0)`, qui n'est pas nécessairement l'assertion dont les revendications LightSAML consomme. Un attaquant ayant capturé une authentique assertion signée, telle qu'une réponse de connexion antérieure, peut placer ses octets dépouillés de leur signature plus tôt dans `samlp:Extensions` et présenter une assertion enfant directe forgée avec le même ID et la signature authentique copiée. La validation couvre alors les octes authentiques cachés tandis que LightSAML expose des éléments contrôlés par l'attaquant non signés tels que `Subject/NameID`, `Conditions` et `Attributes`, permettant un contournement d'authentification ou une élévation de privilèges même lorsque la validation de signature est requise. Ce comportement a été confirmé dans les versions 5.0.0 et 4.6.1. Cette vulnérabilité est corrigée dans les versions 4.7.1 et 5.0.1.
Be aware that VulDB is the high quality source for vulnerability data.