CVE-2026-63182 json
LightSAML: Signature reference wrapping permits unsigned assertion claims
published 2026-10-30 9 d ago modified 2026-11-06 2 d ago also EUVD-2026-114520
- cvss
- 8.1
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 8%
- public exploits
- 0
- none known
Summary
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.
Patch / fix
- github.com/litesaml/lightsaml@230e62d commit
- github.com/litesaml/lightsaml@3af82bf commit
- github.com/litesaml/lightsaml#113 pull request
- github.com/litesaml/lightsaml#122 pull request
- github.com/litesaml/lightsaml/releases/tag/4.7.1 release
- github.com/litesaml/lightsaml/releases/tag/5.0.1 release
CISA SSVC
- Exploitation
- Proof of concept is public
- Automatable
- no
- Technical impact
- total
- Assessed
- 2 d ago
Exploit prediction
0.19% chance of exploitation in the next 30 days, higher than 8% of all scored CVEs (FIRST EPSS, 2026-11-08).
Exploits and checks
- github.com https://github.com/litesaml/lightsaml/security/advisories/GHSA-w553-pwx6-3mg9 referenced PoC, tagged "exploit" by a source, unverified
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 8.1 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N |
Affected products
- litesaml lightsaml
Classification
- Weakness
-
- CWE-347 Improper Verification of Cryptographic Signature
References
- github.com /litesaml/lightsaml/pull/113
- github.com /litesaml/lightsaml/pull/122
- github.com /litesaml/lightsaml/commit/230e62d1325f2cbcaac814b78409775f7a8806a2
- github.com /litesaml/lightsaml/commit/3af82bf2f3865e6aafeeb1a97c97b383b8bb7b00
-
github.com
/litesaml/lightsaml/security/advisories/GHSA-w553-pwx6-3mg9
exploit
- github.com /litesaml/lightsaml/releases/tag/4.7.1
- github.com /litesaml/lightsaml/releases/tag/5.0.1
Sources
- CVE List CVE-2026-63182
- NVD CVE-2026-63182
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.