RUSTSEC-2026-0195: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 62/100
Research direction
Start by checking the notarization dependency configuration for quick-xml and whether the project uses NsReader or NamespaceResolver. Upgrade quick-xml to >=0.41.0, then run the repository's existing test suite to confirm the dependency update is complete and does not introduce regressions.
Written by the indexing model from the issue text.
Description
Unbounded namespace-declaration allocation in
NsReaderenables memory-exhaustion denial of service
| Details | |
|---|---|
| Package | quick-xml |
| Version | 0.39.4 |
| URL | https://github.com/tafia/quick-xml/issues/970 |
| Date | 2026-06-29 |
| Patched versions | >=0.41.0 |
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.
See advisory page for additional details.
- Dominant language
- Rust
- Stars
- 5
- Forks
- 7
- Avg merge
- 10h 34m
- Merged PRs (30d)
- 11
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from iotaledger/notarization
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
iotaledger/notarization#326 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
iotaledger/notarization#325 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
iotaledger/notarization#344 ·
-
iotaledger/notarization#340 · 1 assignee ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
iotaledger/notarization#338 ·
All issues in iotaledger/notarization
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
bitcoindevkit/bdk-ffi#1125 ·