Skip to main content

Moov signedxml EUVDEUVD-2026-105774

| CVE-2026-113729 HIGH
Uncontrolled Resource Consumption (CWE-400)
2026-10-20 security-advisories@github.com GHSA-5588-rp99-5fjh
7.5
CVSS 3.1 · Vendor: github
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach XML endpoint using signedxml
  2. Exploit
    Submit small deeply-nested multi-namespace document
  3. Execution
    Trigger quadratic namespace-map copying in canonicalization
  4. Impact
    Exhaust memory and terminate process

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK

1 technique across 1 tactic: Impact

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires that the target application invoke signedxml's ValidateReferences (which triggers ExclusiveCanonicalization) on attacker-controlled XML - the advisory confirms this path needs no valid signature, matching certificate, or prior authentication. The crafted input must specifically use deeply nested elements each declaring many (largely unused) xmlns namespace prefixes, which drives quadratic allocation growth with depth and linear growth with prefixes per level. Limiting factors: the attacker must be able to deliver XML to a code path that performs exclusive canonicalization (typical for SAML/WS-Federation validation), and the installed signedxml version must be prior to 1.4.1; versions 1.4.1+ reject documents exceeding 8192 in-scope namespaces. Impact is confined to availability (memory exhaustion / process crash) and does not bypass signature verification.

Impact

This is a genuine but bounded availability risk - a CWE-400 uncontrolled resource consumption (memory exhaustion) flaw, not a confidentiality or integrity issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the description: the condition is reachable through ValidateReferences over attacker-supplied XML without a valid signature, matching certificate, or prior authentication, so network-reachable, low-complexity, unauthenticated triggering is credible. No EPSS score, CISA KEV listing, or POC was provided in the input, so exploitation status is 'no public exploit identified at time of analysis' - there is no signal of active exploitation. The practical severity is therefore driven by exposure rather than by proven weaponization: any service that calls signedxml's ValidateReferences on untrusted XML (e.g. a SAML/WS-Federation endpoint) can be crashed by a single comparatively small crafted document, but the impact ceiling is process termination, not compromise. Importantly, the advisory explicitly states the issue does NOT bypass signature verification, so this cannot be chained into authentication bypass. Net assessment: patch promptly for internet-facing XML-processing services (easy, pre-auth DoS), but this is availability-only and currently carries no evidence of in-the-wild abuse.

Exploit ScenarioDerived

An attacker sends a single crafted XML document - small on the wire but containing deeply nested elements each carrying many unused xmlns declarations - to a service endpoint that passes untrusted input to signedxml's ValidateReferences (such as a SAML assertion consumer). During exclusive canonicalization the library copies the full accumulated namespace map at every nested element, driving quadratic memory growth until the process consumes multiple gigabytes and is terminated by the OS. No valid signature, certificate, or authentication is needed, and no public POC was provided in the input.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.5% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 21, 2026

Memory exhaustion in the Moov signedxml Go library (versions prior to 1.4.1) allows unauthenticated remote attackers to crash a service by submitting crafted XML that passes through exclusive canonicalization during ValidateReferences. Each nested element causes the library to copy the entire accumulated namespace map, so a modest document with deep nesting and many unused xmlns prefixes balloons to gigabytes of allocation and terminates the process. The flaw does not bypass signature verification and only affects availability; no public exploit code was identified at time of analysis, and the project shipped a fix in v1.4.1 that caps in-scope namespaces at 8192 and replaces whole-map copying with push/pop scope deltas.

RemediationAI

Upgrade the github.com/moov-io/signedxml module to v1.4.1 or later, which bounds retained in-scope namespaces at 8192 and eliminates the per-element namespace map copying (see the release at https://github.com/moov-io/signedxml/releases/tag/v1.4.1 and the advisory at https://github.com/moov-io/signedxml/security/advisories/GHSA-5588-rp99-5fjh); run go get github.com/moov-io/signedxml@v1.4.1 and re-run go mod tidy so indirect consumers are also bumped. Where upgrading is not immediately possible, apply compensating controls at the perimeter: cap the size of inbound SAML/XML bodies at the reverse proxy or application handler (e.g., http.MaxBytesReader) to a few hundred kilobytes, which defeats the multi-gigabyte amplification but will reject unusually large legitimate federation metadata; reject documents whose element nesting exceeds a sane depth or whose xmlns declaration count per element exceeds a small threshold using a streaming pre-scan (encoding/xml Decoder with a depth counter) before handing the payload to ValidateReferences, at the cost of an extra parse pass; and rate-limit or queue XML validation endpoints so a single abusive request cannot exhaust the process heap. Note that none of these controls fix the underlying allocation behavior and that memory limits alone (GOMEMLIMIT, container OOM ceilings) convert the crash into a graceful error rather than preventing the resource consumption.

Affected VersionsENISA

signedxml < 1.4.1

Affected Packages

go github.com/moov-io/signedxml fix: 1.4.1
euvd signedxml fix: 1.4.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

signedxml is a pure-Go implementation of XML Digital Signature processing used chiefly for SAML and WS-Federation assertion validation; it builds on the github.com/beevik/etree DOM. The vulnerable code lives in exclusivecanonicalization.go, which implements Exclusive XML Canonicalization (Exc-C14N) - the transform that normalizes a signed subtree before reference digests and signature values are computed. In the pre-1.4.1 implementation, processRecursive saved the current namespace map and made a full copyNamespace() copy on entry to every element, restoring it on exit. Because a namespace map grows with every distinct xmlns prefix declared anywhere on the path, copying it at each level of a deeply nested, prefix-heavy document produces O(depth x prefixes) allocations - quadratic growth with depth and linear growth with prefixes per level - which is the classic CWE-400 uncontrolled resource consumption pattern. Critically, this work happens during canonicalization, before any digest or signature check, so it is reached through ValidateReferences without a valid signature, matching certificate, or prior authentication. The 1.4.1 fix (commit da2cd6126c4c53b7e59a367d287786e6f6a2d0d3) replaces the copying strategy with nsScopeDelta pushNamespaces/popNamespaces bookkeeping that mutates a single map in place, tracks added prefixes in a set for O(1) membership tests, and introduces the constant maxInScopeNamespaces = 8192, returning an error when the retained prefix-to-URI mapping set is exceeded.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (github) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI 7.5 HIGH

Pre-auth, network-delivered XML processed via ValidateReferences gives AV:N/AC:L/PR:N/UI:N; impact is availability-only memory exhaustion, so C:N/I:N/A:H, scope unchanged.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

2
Patch available
Oct 20, 2026 - 23:20 EUVD
CVE Published
Oct 20, 2026 - 22:19 cve.org
HIGH 7.5

DescriptionCVE.org

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.

Technical POC Analysis

CWE-400 (Uncontrolled Resource Consumption).

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

The Moov signedxml Go library, used in XML signature validation, can be driven to exhaust memory and terminate the host service in versions prior to 1.4.1. This creates an availability risk for any externally reachable application that relies on the library, though the project has released a fixed version and no public exploit identified at time of analysis. Leadership should prioritize dependency remediation because a single crafted request could disrupt service without affecting signature integrity.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.5%
Top 61% exploitable
Prevalence
Low
niche open-source Go XML-signature library, specialized SAML/WS-Fed use
Threat Intel
2
1 sources
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.5%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy