LightSAML EUVD-2026-114520

The attacker must already possess at least one genuinely IdP-signed SAML assertion from the trusted issuer (e.g. a captured earlier login response or their own legitimate low-privilege assertion); without a valid signature to copy, the wrap cannot pass. The target must be a Service Provider using LightSAML prior to 4.7.1 (4.x branch) or 5.0.1 (5.x branch) together with robrichards/xmlseclibs for inbound samlp:Response assertion signature validation. The flaw triggers precisely because Response::deserialize collects only direct-child saml:Assertion elements while xmlseclibs resolves Reference URI="#id" through //*[@Id] item(0) document-wide; this works even with signature validation required (requireSignature=true) and against default per-assertion validation, so no non-default configuration is needed. Limiting factors: exploitation is bounded by the need to obtain a valid signed assertion from the specific trusted IdP, and complete remediation requires upgrading to a fixed version.

This is a genuine high-priority signature-verification flaw (CWE-347) rather than an inflated high-CVSS issue. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N = 8.1) is consistent with the mechanism: an inbound SAML Response is delivered over the network, the XML Signature Wrapping technique is deterministic (xmlseclibs always resolves //*[@Id] item(0), the first ID-bearing element in document order), and the outcome is full authentication bypass or privilege escalation. The PR:L in the input is defensible because the attacker must first possess at least one genuinely IdP-signed assertion (plausibly their own earlier low-privilege login), which is a meaningful precondition and the reason this reads as privilege escalation rather than pure anonymous bypass. EPSS is NOT provided in the input, so exploitation probability cannot be quantified. There is NO CISA KEV entry in the input, so this is not confirmed as actively exploited. No formal SSVC decision tuple (exploitation/automatable/technical impact) is supplied; the only decision signal is the vuln.today priority label 'this_week', which indicates prompt but not emergency remediation. A complete, working reproduction PoC (composer install plus xmlsec1 signing and a PHP tamper script against LightSAML 5.0.0) is published directly in the GHSA advisory, which materially raises real-world risk even without KEV confirmation. Net: prioritize patching within the week as the decision label indicates - the combination of a trivial, reliable, published exploit and a complete auth-bypass impact outweighs the absence of EPSS and KEV data, which reflect measurement gaps here rather than low risk.

An attacker who has captured one genuinely IdP-signed SAML assertion - for example their own earlier legitimate login response - strips its ds:Signature and buries those genuine bytes inside samlp:Extensions so they become the first @Id element in document order, then presents a single forged direct-child saml:Assertion carrying the same ID, a verbatim copy of the genuine signature, and attacker-chosen Subject/NameID, Conditions, and Attributes (e.g. role=admin). xmlseclibs validates the copied signature against the hidden genuine element and passes, while LightSAML reads claims from the forged direct-child assertion, yielding authentication bypass or privilege escalation even with signature validation required. A full working PoC is published in the GHSA-w553-pwx6-3mg9 advisory.