Description
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.
Published: 2026-10-30
Score: 8.1 High
EPSS: n/a
KEV: No
Impact: Authentication bypass and potential privilege escalation through forged SAML assertions
Action: Immediate Patch
AI Analysis

Impact

LightSAML, a library for handling SAML 2.0 messages, misinterprets which XML element a digital signature covers. When deserializing SAML Responses, the library validates a signature that may refer to a different node than the assertion it later processes. An attacker can embed a genuine signature into an earlier, signature‑striped part of the response and then inject a forged assertion containing the same ID and signature. As a result, the library believes the data is signed while in reality it accepts unsigned, attacker‑controlled Subject, Conditions, and Attribute values, enabling authentication bypass or privilege escalation.

Affected Systems

The vulnerability affects all installations of litesaml:lightsaml older than versions 4.7.1 and 5.0.1. Systems that rely on this library to validate SAML tokens in web or service applications are impacted; no other vendors are listed.

Risk and Exploitability

The CVSS score of 8.1 marks this flaw as high severity. EPSS data is not available, and the vulnerability is not listed in CISA’s KEV catalog, suggesting it is not currently exploited in the wild. The most likely attack vector is via network channels that deliver SAML responses from an IdP to a relying party—an inferred scenario based on the SAML protocol flow. If an attacker can supply crafted responses, they can bypass authentication checks without tampering with the signature verification process.

Generated by OpenCVE AI on October 30, 2026 at 23:28 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade LightSAML to version 4.7.1 or later, or 5.0.1 or later
  • Ensure the application validates that the signature reference URI points precisely to the assertion node being used, rejecting any response where they diverge
  • Configure the relying party to accept only SAML assertions that contain a signature and that have a matching Issuer, ID, and subject claim verified against the signed data

Generated by OpenCVE AI on October 30, 2026 at 23:28 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 30 Oct 2026 22:00:00 +0000

Type Values Removed Values Added
Description 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.
Title LightSAML: Signature reference wrapping permits unsigned assertion claims
Weaknesses CWE-347
References
Metrics cvssV3_1

{'score': 8.1, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N'}


Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published:

Updated: 2026-10-30T21:46:38.551Z

Reserved: 2026-07-15T22:13:00.721Z

Link: CVE-2026-63182

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-30T22:16:58.280

Modified: 2026-10-30T22:16:58.280

Link: CVE-2026-63182

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-30T23:30:15Z

Weaknesses
  • CWE-347

    Improper Verification of Cryptographic Signature