RUSTSEC-2026-0195
ADVISORY - rustsecSummary
NsReader resolves namespaces by calling NamespaceResolver::push for every
Start/Empty event before the event is returned to the caller. push
iterated all xmlns / xmlns:* attributes on the start tag and, for each one,
appended the prefix bytes to an internal buffer and pushed a NamespaceBinding
(32 bytes on 64-bit) to an internal Vec, with no upper bound on the number of
declarations.
Impact
A start tag with N namespace declarations drove roughly 3× the tag's byte
size in NamespaceResolver heap, allocated inside quick-xml before the
NsReader consumer ever received the event and could inspect or reject it. A
consumer that bounds its input size therefore still cannot bound this
allocation: an M-byte start tag yields on the order of 3 × M bytes of
resolver heap the caller never sees.
On untrusted XML this lets a remote, unauthenticated attacker force large heap
allocations with a single start tag. With several NsReaders running
concurrently on independent inputs (a common server pattern), the allocations
stack and can exhaust process memory, causing the operating system to kill the
process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
Labs Routinator), where concurrent RRDP validation workers parsing a crafted
snapshot.xml exceeded the memory limit and the process was OOM-killed.
Affected code paths
Consumers using NsReader (which always calls NamespaceResolver::push before
yielding Start/Empty), or calling NamespaceResolver::push directly. A plain
Reader that does not perform namespace resolution is not affected.
Remediation
Upgrade to quick-xml >= 0.41.0. NamespaceResolver::push now rejects a start
tag that declares more than DEFAULT_MAX_DECLARATIONS_PER_ELEMENT (256)
namespace bindings, returning the new NamespaceError::TooManyDeclarations
instead of allocating without limit. The limit is configurable via
NamespaceResolver::set_max_declarations_per_element (use usize::MAX to
restore the previous unbounded behavior), and NsReader::resolver_mut() is
provided to reach it.
There is no clean workaround for NsReader consumers before 0.41.0, as the
allocation happens inside the reader with no configuration knob to cap it.
Common Weakness Enumeration (CWE)
RustSec
3.9
CVSS SCORE
7.5high| Package | Type | OS Name | OS Version | Affected Ranges | Fix Versions |
|---|---|---|---|---|---|
| quick-xml | cargo | - | - | <0.41.0 | 0.41.0 |
CVSS:3 Severity and metrics
The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification.
The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).
Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.
The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
The vulnerable system can be exploited without interaction from any user.
An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
There is no loss of confidentiality.
There is no loss of trust or accuracy within the impacted component.
There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component.