📌 이 취약점에 대해 확인된 사실
전부 발행처가 발표한 값입니다. 우리가 계산하거나 판단한 숫자는 하나도 없습니다.
악용 여부
심각도 (발행처 발표값)
높음8.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
악용 확률 (EPSS)
0.2%
📄 원문 그대로
아래 문장은 전부 발행처가 쓴 것입니다. 번역하지 않습니다 — 보안 문서의 오역은 조치를 바꿉니다.
취약점 설명 (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.
참고
악용 확률 변화
우리가 매일 저장한 EPSS 스냅샷입니다. 원본은 전날 값만 주므로, 이 표는 수집을 시작한 이후만 보여줍니다.
| 기준일 | 확률 | 백분위 |
|---|---|---|
| 2026-11-03 | 0.15% | 4.3% |
| 2026-11-02 | 0.15% | 4.3% |
| 2026-11-01 | 0.15% | 4.3% |
| 2026-10-31 | 0.15% | 4.3% |
🧩 같은 약점 유형 — CWE-347
같은 분류의 다른 취약점입니다. 같은 실수가 제품을 가리지 않고 반복됩니다.