CVE-2026-33487

What it actually does

The flaw is an XML Digital Signature validation weakness in goxmlsig before version 1.6.0. During signature validation, the library iterates through SignedInfo Reference entries to find the reference matching the signed element ID, but in affected builds it can retain a pointer to the loop variable rather than the matched reference value. In Go versions before 1.22, or projects compiled with older Go module semantics, this can cause the selected reference to resolve to the last entry in the SignedInfo.References slice instead of the intended signed element. An attacker who can supply a crafted XML document with multiple Reference entries may cause the application to validate the wrong digest/reference relationship, potentially accepting attacker-controlled XML content as if it were correctly signed. The primary security impact is integrity compromise of signature-backed trust decisions.

Why it matters to the business

Applications that rely on goxmlsig to validate signed XML, such as SAML-like assertions, identity documents, payment or workflow messages, configuration bundles, or other trust-bearing XML payloads, may make authorization or business decisions based on data that was not actually protected by the expected signature. This can result in unauthorized access, falsified transaction data, bypassed approval workflows, or acceptance of tampered records. The CVSS score indicates high integrity impact, but the currently reported EPSS is low, there is no known CISA KEV listing, no known ransomware association, and no public exploit maturity reported, so remediation should be prioritized for exposed or security-critical XML signature validation paths rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first identifies an application or service that accepts externally supplied signed XML and validates it using an affected version of goxmlsig under vulnerable Go loop-variable semantics. The attacker then crafts an XML document containing a signed element and a SignedInfo block with multiple Reference entries arranged so that validation logic selects or effectively points to the wrong reference, commonly the last reference in the slice rather than the intended matched reference. If the application trusts the validated XML content after goxmlsig reports success, attacker-controlled fields may be processed as authentic even though the signature validation did not bind the trusted content correctly. Successful exploitation depends on the surrounding XML trust model: the flaw is most dangerous where validation results directly control authentication, authorization, financial, provisioning, or policy decisions.

How to fix it

Upgrade goxmlsig to version 1.6.0 or later wherever the library is used. Rebuild and redeploy all applications and services that statically include the vulnerable dependency, since Go binaries commonly vendor or compile dependencies into the executable. Also build with a modern supported Go toolchain, preferably Go 1.22 or later, and verify module settings do not preserve older vulnerable loop-variable behavior. Where immediate upgrade is not possible, reduce exposure by rejecting signed XML from untrusted sources, enforcing strict XML schema and signature-profile validation, requiring exactly the expected Reference structure, rejecting duplicate or unexpected Reference entries, and adding application-level checks that the signed element ID, digest, and consumed business object are the same object. Treat mitigation as temporary; the durable fix is upgrading to goxmlsig 1.6.0 or later and redeploying dependent applications.

How to confirm the fix worked

Confirm dependency remediation by checking go.mod, go.sum, vendored modules, software composition analysis output, and build manifests for github.com/russellhaering/goxmldsig or equivalent goxmlsig package versions earlier than 1.6.0. Confirm the deployed binary was rebuilt after the dependency upgrade; source changes alone are insufficient for statically compiled Go services. Verify the Go toolchain and module semantics used for builds are Go 1.22 or later where applicable. Add or run regression tests with XML documents containing multiple SignedInfo Reference elements, duplicate or unexpected Reference IDs, and intentionally mismatched signed content; validation should fail unless the exact expected element and digest are signed and consumed. For externally reachable services, test only with authorized safe proof-of-concept XML payloads that do not alter production data.

Typical attack path

1. Find an endpoint, API, broker, identity flow, or file import process that accepts signed XML from untrusted or semi-trusted sources.
2. Determine or infer that the target application uses goxmlsig before version 1.6.0 and is built with Go versions or module semantics affected by loop-variable capture behavior.
3. Create a signed XML payload with multiple SignedInfo Reference entries, including a reference layout intended to confuse the validator's selected reference.
4. Place attacker-controlled or modified XML data in fields the application will later trust after signature validation.
5. Submit the crafted XML to the target service or workflow.
6. If validation succeeds incorrectly, abuse the trusted tampered XML content to gain unauthorized access, alter records, approve actions, or trigger downstream business logic.

How to detect it

Look for evidence of crafted signed XML submitted to services that use goxmlsig, especially documents with multiple ds:Reference elements, duplicate or unusual URI fragment IDs, unexpected Reference ordering, or a mismatch between the signed element and the element consumed by business logic. Relevant log sources include application request logs, API gateway or reverse-proxy logs, XML validation error logs, authentication or federation logs, message broker payload archives, audit logs for signed-document workflows, and transaction records created from signed XML. Because exploitation may not produce a crash or obvious error, correlate suspicious signed-XML submissions with successful authentication, authorization, provisioning, payment, or approval actions that have unusual field values. If payload logging is available, search historical XML bodies for SignedInfo blocks with more Reference elements than expected. In forensic review, compare stored signed XML artifacts against downstream parsed records to identify cases where unsigned or differently referenced XML fields were accepted. There are no widely reported public exploit indicators, named threat actors, or KEV activity for this issue as provided, so detection should focus on malformed signature structure and anomalous business outcomes rather than known attacker infrastructure.

• <SignedInfo
• <ds:SignedInfo
• <Reference URI="#
• <ds:Reference URI="#
• </Reference><Reference
• </ds:Reference><ds:Reference
• <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
• http://www.w3.org/2000/09/xmldsig#
• github.com/russellhaering/goxmldsig
• goxmldsig v1.5.
• goxmldsig v1.4.
• goxmldsig v1.3.
• goxmldsig v1.2.
• goxmldsig v1.1.
• goxmldsig v1.0.

What your security team should do

• Inventory all applications, services, command-line tools, and data-processing jobs that parse or validate signed XML using goxmlsig.
• Prioritize upgrades for internet-facing services, identity/authentication flows, payment or transaction processors, provisioning systems, and any workflow where signed XML controls authorization or approval decisions.
• Upgrade goxmlsig to version 1.6.0 or later, rebuild binaries, and redeploy affected services.
• Ensure build pipelines use a supported Go toolchain, preferably Go 1.22 or later, and verify module settings do not preserve older loop-variable behavior.
• Add negative security tests for XML signatures with multiple Reference entries, duplicate IDs, unexpected transforms, and mismatched signed versus consumed elements.
• Review recent signed-XML transaction logs for anomalous multiple-reference documents or validation failures followed by successful retries.
• Temporarily restrict acceptance of signed XML from untrusted sources or enforce strict signature profiles if immediate patching is not possible.
• Document where XML signature validation is a security boundary and add dependency-monitoring alerts for future goxmlsig and XML signature parser advisories.