Katalog CVE

CVE-2026-63182

WysokieCVSS 8.1
Opublikowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.15%

Percentyl 4 - wyżej niż 4% wszystkich znanych CVE

Streszczenie

W bibliotece LightSAML przed wersjami 4.7.1 i 5.0.1 występuje niezgodność z xmlseclibs co do tego, którą asercję obejmuje podpis SAML. XMLSecurityDSig::validateReference() usuwa podpis z współdzielonego DOM, ale processRefNode() rozwiązuje Reference URI="#id" w całym dokumencie przez XPath //*[@Id] i bierze item(0), co nie musi być asercją, której dane LightSAML wykorzystuje. Atakujący z przechwyconą prawdziwie podpisaną asercją może umieścić jej bajty bez podpisu w samlp:Extensions i przedstawić sfałszowaną asercję z tym samym ID i skopiowanym podpisem, co umożliwia obejście uwierzytelniania lub eskalację uprawnień.

Ocena ryzyka

Może umożliwić obejście uwierzytelniania SAML lub eskalację uprawnień nawet przy wymaganej walidacji podpisu. Ryzyko dotyczy dostawców usług i tożsamości korzystających z LightSAML.

Rekomendacja

Zaktualizuj LightSAML do wersji 4.7.1 lub 5.0.1 (lub nowszej). Zweryfikuj konfigurację walidacji podpisów SAML i monitoruj nietypowe asercje.

Powiązane podatności

Oryginalny opis (angielski, źródło NVD)

LightSAML implements SAML 2.0 data model classes, XML serialization and deserialization, XML security, certificate support, and message bindings. Prior to 4.7.1 and 5.0.1, LightSAML and xmlseclibs disagree about which assertion an inbound SAML signature covers. `Response::deserialize` uses `manyElementsFromXml` to collect only direct-child `saml:Assertion` elements of `samlp:Response`, and `AssertionSignatureValidatorAction` validates their `ds:Signature` using an out-of-band trusted IdP credential resolved by Issuer, not a key from the document. `XMLSecurityDSig::validateReference()` removes the enveloped signature from the shared DOM, but `processRefNode()` resolves `Reference URI="#id"` document-wide through an XPath of the form `//*[@Id]` and takes `item(0)`, which need not be the assertion whose claims LightSAML consumes. An attacker who has captured one genuinely signed assertion, such as an earlier login response, can place its signature-stripped bytes earlier in `samlp:Extensions` and present a forged direct-child assertion with the same ID and copied genuine signature. Validation then covers the hidden genuine bytes while LightSAML surfaces unsigned attacker-controlled `Subject/NameID`, `Conditions`, and `Attributes`, enabling authentication bypass or privilege escalation even when signature validation is required. The behavior was confirmed in versions 5.0.0 and 4.6.1. This issue is fixed in versions 4.7.1 and 5.0.1.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS