CVE-2026-63182

LightSAML implementuje klasy modelu danych SAML 2.0, serializację i deserializację XML, bezpieczeństwo XML, obsługę certyfikatów i powiązania komunikatów. W wersjach wcześniejszych niż 4.7.1 i 5.0.1 LightSAML i xmlseclibs nie zgadzały się co do tego, które potwierdzenie obejmuje przychodzący podpis SAML. `Response::deserialize` używa `manyElementsFromXml` do zbierania tylko bezpośrednich elementów `saml:Assertion` z `samlp:Response`, a `AssertionSignatureValidatorAction` weryfikuje ich `ds:Signature` przy użyciu pozapasmowego zaufanego poświadczenia dostawcy tożsamości rozwiązanego przez wystawcę, a nie klucza z dokumentu. `XMLSecurityDSig::validateReference()` usuwa podpis w kopercie ze współdzielonego modelu DOM, ale `processRefNode()` rozwiązuje `Reference URI="#id"` w całym dokumencie poprzez ścieżkę XPath w postaci `//*[@Id]` i pobiera `item(0)`, który nie musi być asercją, której oświadczenia wykorzystuje LightSAML. Osoba atakująca, która przechwyciła jedno autentycznie podpisane potwierdzenie, np. wcześniejszą odpowiedź na logowanie, może umieścić pozbawione podpisu bajty wcześniej w `samlp:Extensions` i przedstawić sfałszowaną asercję bezpośredniego dziecka z tym samym identyfikatorem i skopiowanym prawdziwym podpisem. Następnie walidacja obejmuje ukryte, autentyczne bajty, podczas gdy LightSAML ujawnia kontrolowane przez atakującego niepodpisane „ID podmiotu/nazwy”, „warunki” i „atrybuty”, umożliwiając obejście uwierzytelnienia lub eskalację uprawnień nawet wtedy, gdy wymagana jest weryfikacja podpisu. Zachowanie zostało potwierdzone w wersjach 5.0.0 i 4.6.1. Ten problem został rozwiązany w wersjach 4.7.1 i 5.0.1.