CVE-2026-33487: 
Grafana vulnerability analysis and mitigation

CVE-2026-33487 is a loop variable capture vulnerability in the validateSignature function of goxmldsig (github.com/russellhaering/goxmldsig), a Go library implementing XML Digital Signatures. The flaw allows unauthenticated remote attackers to bypass XML signature verification by causing the validation logic to evaluate the wrong signature reference. All versions up to and including v1.5.0 are affected; version 1.6.0 contains the fix. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause is a classic Go loop variable capture bug (CWE-347, CWE-682) in validate.go (lines 309–313). In Go versions prior to 1.22, the loop variable _ref is allocated once for the entire loop body; taking its address (&_ref) means the stored pointer always refers to the same memory location, which holds the last value assigned during iteration. Consequently, when validateSignature iterates over SignedInfo.References to find the reference matching the signed element's ID, the captured ref pointer ends up pointing to the final element in the slice regardless of which reference actually matched. An attacker can craft a multi-reference signed document so that the reference validated is not the one covering the tampered element, effectively bypassing integrity verification. A public PoC written in Go demonstrates the bypass by constructing a signed document with two references, altering the first element's content, and confirming that valCtx.Validate() still returns success (GitHub Advisory).

Successful exploitation allows an unauthenticated attacker to forge or manipulate XML Digital Signatures, causing the library to accept tampered XML documents as validly signed. The primary impact is a high integrity loss: any application relying on goxmldsig for authentication or authorization decisions (e.g., SAML-based SSO, signed API messages, or document integrity checks) could be deceived into trusting malicious content. There is no direct confidentiality or availability impact, but a signature bypass can enable privilege escalation, identity spoofing, or injection of malicious payloads into downstream processing pipelines (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, demonstrating the bypass with a self-contained Go program requiring no external infrastructure (GitHub Advisory). The vulnerability requires no authentication, no user interaction, and is exploitable over the network with low attack complexity. The EPSS score is approximately 0.02% (0.000200), indicating low current exploitation probability, and there is no evidence of in-the-wild exploitation or CISA KEV listing at this time. Detection coverage exists via Nessus (plugin 304089) and multiple Qualys detection IDs.

1. Identify target: Locate an application that uses goxmldsig v1.5.0 or earlier for XML Digital Signature validation (e.g., a SAML service provider or XML-signing API endpoint).
2. Generate a legitimate signed document: Use a valid signing key to produce a signed XML document containing two elements, each with its own <Reference> entry in SignedInfo.
3. Craft the malicious document: Modify the first element's content (the one you wish to tamper with) to contain attacker-controlled data. Ensure the second reference (covering a legitimately signed element) remains intact and will be the last entry in SignedInfo.References.
4. Exploit the loop capture bug: When the vulnerable validateSignature function iterates over references, the ref pointer ends up pointing to the last reference (the valid one) due to the loop variable capture bug, even though the matched reference was the first one covering the tampered element.
5. Submit the tampered document: Send the crafted XML to the target application's validation endpoint. The library calls valCtx.Validate(), which returns success because it verifies the last (valid) reference rather than the one covering the tampered content.
6. Achieve objective: The application accepts the tampered XML as authentically signed, enabling identity spoofing, authorization bypass, or injection of malicious content into downstream processing (GitHub Advisory).

• Network: Unexpected or malformed XML payloads containing multiple <Reference> elements within a single <SignedInfo> block submitted to XML signature validation endpoints; unusual SAML assertion traffic with multiple digest references.
• Logs: Application logs showing successful XML signature validation for documents with mismatched or duplicate reference URIs; validation success immediately followed by unexpected authorization grants or privilege changes.
• File System: Presence of Go binaries or scripts referencing the goxmldsig PoC pattern (multi-reference signed XML generation) in attacker-accessible directories.
• Process Behavior: Unexpected downstream actions (account creation, privilege escalation, data modification) triggered immediately after XML signature validation events in applications using goxmldsig.

Upgrade goxmldsig to version 1.6.0, which fixes the loop variable capture by iterating with an index (for i := range signedInfo.References) and taking the address of the slice element directly (&signedInfo.References[i]), with an early break on first match (GitHub Advisory). As a secondary mitigation, upgrading to Go 1.22 or later changes loop variable semantics so each iteration gets its own variable allocation, which would also prevent this class of bug. If immediate patching is not possible, audit all XML signature validation flows for documents containing multiple references and consider rejecting any signed document with more than one <Reference> element as a temporary defensive measure.

The vulnerability was reported by researcher Tomas Illuminati and published via GitHub's security advisory system on March 18, 2026 (GitHub Advisory). The openSUSE security announce list issued a notification covering this CVE as part of govulncheck/vulndb updates, indicating downstream Linux distribution awareness (openSUSE Advisory). Coverage appeared on Mastodon via @thehackerwire and in German Linux security news (pro-linux.de), reflecting moderate community interest given the library's use in SAML and XML signing workflows.