CVE-2026-113729

Moov signedxml is a pure Go library for processing signed XML documents. Prior to 1.4.1, ExclusiveCanonicalization in exclusivecanonicalization.go copies the complete accumulated namespace map at every nested element before reference digest or signature checks. Attacker-controlled XML containing deeply nested elements with many unused namespace declarations causes quadratic allocation growth with depth and linear growth with prefixes per level, allowing a comparatively small document to consume multiple gigabytes of memory and terminate the process. The condition is reachable through ValidateReferences without a valid signature, matching certificate, or prior authentication, and it does not bypass signature verification. This issue is fixed in version 1.4.1.

Moov signedxml is a pure Go library for processing signed XML documents. Prior to 1.4.1, ExclusiveCanonicalization in exclusivecanonicalization.go copies the complete accumulated namespace map at every nested element before reference digest or signature checks. Attacker-controlled XML containing deeply nested elements with many unused namespace declarations causes quadratic allocation growth with depth and linear growth with prefixes per level, allowing a comparatively small document to consume multiple gigabytes of memory and terminate the process. The condition is reachable through ValidateReferences without a valid signature, matching certificate, or prior authentication, and it does not bypass signature verification. This issue is fixed in version 1.4.1.

Exclusive XML canonicalization (http://www.w3.org/2001/10/xml-exc-c14n#) in github.com/moov-io/signedxml copied the entire accumulated namespace map at every node during ValidateReferences(), before any reference digest or signature check.

For a chain of nested elements that each declare many unused namespace prefixes, that produced O(m × depth²) time and peak memory (m = prefixes per level). beevik/etree caps tree depth (~1024), but m is unbounded, so a small attacker-controlled document (on the order of 1 MB) could drive multi-gigabyte allocations and OOM the process. No valid signature, matching certificate, or authentication is required.

This is the library’s core path for SAML / WS-Federation service providers, which canonicalize attacker-supplied XML prior to authentication.

Affected

• Package: github.com/moov-io/signedxml
• Function: ExclusiveCanonicalization (exclusivecanonicalization.go)
• Verified: v1.4.0 and current default branch (commit d79064a). Earlier v1.2.x–v1.3.x releases are likely affected.

Remediation

Do not copy the whole namespace map per node. Maintain a single scope and push/pop only the prefixes introduced at each element. Replace linear prefix-in-scope scans with set lookups. Impose a defensive cap on in-scope namespace declarations and return an error rather than allocating unbounded memory.

From @shuji-oh

Thanks for the fix — I re-ran my PoC against this branch and confirmed the memory blowup is gone.

Before (main)

-- Doubling depth each time (m=10 fixed): allocated grows ~4x each time ≈ O(depth^2) --
depth=250  m=10  payload=  0.07MB allocated=     45MB
depth=500  m=10  payload=  0.14MB allocated=    179MB
depth=1000 m=10  payload=  0.27MB allocated=    711MB
-- Increasing m (depth=1000 fixed): allocated scales roughly linearly with m --
depth=1000 m=5   payload=  0.16MB allocated=    377MB
depth=1000 m=100 payload=  2.57MB allocated=   6278MB
After (fix/exc-c14n-namespace-dos)

-- Doubling depth each time (m=10 fixed): allocated grows ~4x each time ≈ O(depth^2) --
depth=250  m=10  payload=  0.07MB allocated=      2MB
depth=500  m=10  payload=  0.14MB allocated=      4MB
depth=1000 m=10  payload=  0.27MB allocated=      7MB
-- Increasing m (depth=1000 fixed): allocated scales roughly linearly with m --
depth=1000 m=5   payload=  0.16MB allocated=      4MB
depth=1000 m=100 payload=  2.57MB allocated=     47MB
That's roughly a 100–130x reduction in peak allocation for the same payload sizes, and no OOM in any of my runs. This looks like it resolves the issue — thanks for the quick fix!

Credit

Reported by Shuji Ohira (@shuji-oh).

Moov signedxml is a pure Go library for processing signed XML documents. Prior to 1.4.1, ExclusiveCanonicalization in exclusivecanonicalization.go copies the complete accumulated namespace map at every nested element before reference digest or signature checks. Attacker-controlled XML containing deeply nested elements with many unused namespace declarations causes quadratic allocation growth with depth and linear growth with prefixes per level, allowing a comparatively small document to consume multiple gigabytes of memory and terminate the process. The condition is reachable through ValidateReferences without a valid signature, matching certificate, or prior authentication, and it does not bypass signature verification. This issue is fixed in version 1.4.1.

Moov signedxml is a pure Go library for processing signed XML documents. Prior to 1.4.1, ExclusiveCanonicalization in exclusivecanonicalization.go copies the complete accumulated namespace map at every nested element before reference digest or signature checks. Attacker-controlled XML containing deeply nested elements with many unused namespace declarations causes quadratic allocation growth with depth and linear growth with prefixes per level, allowing a comparatively small document to consume multiple gigabytes of memory and terminate the process. The condition is reachable through ValidateReferences without a valid signature, matching certificate, or prior authentication, and it does not bypass signature verification. This issue is fixed in version 1.4.1.

Exclusive XML canonicalization (http://www.w3.org/2001/10/xml-exc-c14n#) in github.com/moov-io/signedxml copied the entire accumulated namespace map at every node during ValidateReferences(), before any reference digest or signature check.

For a chain of nested elements that each declare many unused namespace prefixes, that produced O(m × depth²) time and peak memory (m = prefixes per level). beevik/etree caps tree depth (~1024), but m is unbounded, so a small attacker-controlled document (on the order of 1 MB) could drive multi-gigabyte allocations and OOM the process. No valid signature, matching certificate, or authentication is required.

This is the library’s core path for SAML / WS-Federation service providers, which canonicalize attacker-supplied XML prior to authentication.

Affected

• Package: github.com/moov-io/signedxml
• Function: ExclusiveCanonicalization (exclusivecanonicalization.go)
• Verified: v1.4.0 and current default branch (commit d79064a). Earlier v1.2.x–v1.3.x releases are likely affected.

Remediation

Do not copy the whole namespace map per node. Maintain a single scope and push/pop only the prefixes introduced at each element. Replace linear prefix-in-scope scans with set lookups. Impose a defensive cap on in-scope namespace declarations and return an error rather than allocating unbounded memory.

From @shuji-oh

Thanks for the fix — I re-ran my PoC against this branch and confirmed the memory blowup is gone.

Before (main)

-- Doubling depth each time (m=10 fixed): allocated grows ~4x each time ≈ O(depth^2) --
depth=250  m=10  payload=  0.07MB allocated=     45MB
depth=500  m=10  payload=  0.14MB allocated=    179MB
depth=1000 m=10  payload=  0.27MB allocated=    711MB
-- Increasing m (depth=1000 fixed): allocated scales roughly linearly with m --
depth=1000 m=5   payload=  0.16MB allocated=    377MB
depth=1000 m=100 payload=  2.57MB allocated=   6278MB
After (fix/exc-c14n-namespace-dos)

-- Doubling depth each time (m=10 fixed): allocated grows ~4x each time ≈ O(depth^2) --
depth=250  m=10  payload=  0.07MB allocated=      2MB
depth=500  m=10  payload=  0.14MB allocated=      4MB
depth=1000 m=10  payload=  0.27MB allocated=      7MB
-- Increasing m (depth=1000 fixed): allocated scales roughly linearly with m --
depth=1000 m=5   payload=  0.16MB allocated=      4MB
depth=1000 m=100 payload=  2.57MB allocated=     47MB
That's roughly a 100–130x reduction in peak allocation for the same payload sizes, and no OOM in any of my runs. This looks like it resolves the issue — thanks for the quick fix!

Credit

Reported by Shuji Ohira (@shuji-oh).