CVE-2026-63182 in LightSAML
Sumário
de VulDB • 30/10/2026
LightSAML implementa classes do modelo de dados SAML 2.0, serialização e desserialização XML, segurança XML, suporte a certificados e bindings de mensagens. Antes das versões 4.7.1 e 5.0.1, o LightSAML e o xmlseclibs discordam sobre qual asserção é coberta pela assinatura SAML entrante. `Response::deserialize` usa `manyElementsFromXml` para coletar apenas os elementos filhos diretos `saml:Assertion` de `samlp:Response`, e `AssertionSignatureValidatorAction` valida suas assinaturas `ds:Signature` usando credenciais confiáveis do IdP resolvidas fora da banda (out-of-band) pelo Emissor, não uma chave presente no documento. `XMLSecurityDSig::validateReference()` remove a assinatura envelopada do DOM compartilhado, mas `processRefNode()` resolve o URI de Referência `"#id"` em todo o documento por meio de um XPath na forma `//*[@Id]` e seleciona `item(0)`, que não precisa ser a asserção cujas afirmações o LightSAML consome. Um atacante que capturou uma asserção genuinamente assinada, como uma resposta de login anterior, pode inserir seus bytes sem assinatura mais cedo em `samlp:Extensions` e apresentar uma asserção filha direta forjada com o mesmo ID e a cópia da assinatura genuína. A validação então cobre os bytes genuínos ocultos enquanto o LightSAML expõe `Subject/NameID`, `Conditions` e `Attributes` controlados pelo atacante e sem assinatura, permitindo bypass de autenticação ou elevação de privilégio mesmo quando a validação de assinatura é exigida. O comportamento foi confirmado nas versões 5.0.0 e 4.6.1. Este problema está corrigido nas versões 4.7.1 e 5.0.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.