fast-xml-parser affected by numeric entity expansion bypassing all entity expansion limits (incomplete fix for CVE-2026-26278) #127
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- javascript
- Domain
- security
Research direction
First verify the target repository: the issue is filed on mapbox-gl-draw but describes fast-xml-parser. If fast-xml-parser is the intended project, inspect src/xmlparser/OrderedObjParser.js, especially replaceEntitiesValue() and the lastEntities and HTML entity loops. Compare their limit tracking with the DOCTYPE path and add tests for numeric and standard entity references before considering the issue done.
Written by the indexing model from the issue text.
Description
| Package | Affected versions | Patched version |
|---|---|---|
| 📦 fast-xml-parser (npm) | >= 4.0.0-beta.3, < 4.5.5 | 4.5.5 |
Summary
The fix for CVE-2026-26278 added entity expansion limits (maxTotalExpansions, maxExpandedLength, maxEntityCount, maxEntitySize) to prevent XML entity expansion Denial of Service. However, these limits are only enforced for DOCTYPE-defined entities. Numeric character references (&#NNN; and &#xHH;) and standard XML entities (<, >, etc.) are processed through a separate code path that does NOT enforce any expansion limits.
An attacker can use massive numbers of numeric entity references to completely bypass all configured limits, causing excessive memory allocation and CPU consumption.
Affected Versions
fast-xml-parser v5.x through v5.5.3 (and likely v5.5.5 on npm)
Root Cause
In src/xmlparser/OrderedObjParser.js, the replaceEntitiesValue() function has two separate entity replacement loops:
- Lines 638-670: DOCTYPE entities — expansion counting with
entityExpansionCountandcurrentExpandedLengthtracking. This was the CVE-2026-26278 fix. - Lines 674-677:
lastEntitiesloop — replaces standard entities includingnum_dec(/&#([0-9]{1,7});/g) andnum_hex(/&#x([0-9a-fA-F]{1,6});/g). This loop has NO expansion counting at all.
The numeric entity regex replacements at lines 97-98 are part of lastEntities and go through the uncounted loop, completely bypassing the CVE-2026-26278 fix.
Proof of Concept
const { XMLParser } = require('fast-xml-parser');
// Even with strict explicit limits, numeric entities bypass them
const parser = new XMLParser({
processEntities: {
enabled: true,
maxTotalExpansions: 10,
maxExpandedLength: 100,
maxEntityCount: 1,
maxEntitySize: 10
}
});
// 100K numeric entity references -- should be blocked by maxTotalExpansions=10
const xml = `<root>${'A'.repeat(100000)}</root>`;
const result = parser.parse(xml);
// Output: 500,000 chars -- bypasses maxExpandedLength=100 completely
console.log('Output length:', result.root.length); // 500000
console.log('Expected max:', 100); // limit was 100
Results:
- 100K
Areferences → 500,000 char output (5x default maxExpandedLength of 100,000) - 1M references → 5,000,000 char output, ~147MB memory consumed
- Even with
maxTotalExpansions=10andmaxExpandedLength=100, 10K references produce 50,000 chars - Hex entities (
A) exhibit the same bypass
Impact
Denial of Service — An attacker who can provide XML input to applications using fast-xml-parser can cause:
- Excessive memory allocation (147MB+ for 1M entity references)
- CPU consumption during regex replacement
- Potential process crash via OOM
This is particularly dangerous because the application developer may have explicitly configured strict entity expansion limits believing they are protected, while numeric entities silently bypass all of them.
Suggested Fix
Apply the same entityExpansionCount and currentExpandedLength tracking to the lastEntities loop (lines 674-677) and the HTML entities loop (lines 680-686), similar to how DOCTYPE entities are tracked at lines 638-670.
Workaround
Set htmlEntities:false
- Dominant language
- JavaScript
- Stars
- 1.1k
- Forks
- 610
- Avg merge
- 54m
- Merged PRs (30d)
- 4
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing 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 mapbox/mapbox-gl-draw
-
auto-triaged bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
mapbox/mapbox-gl-draw#1080 ·
Maintainers usually reply within 1 day
-
auto-triaged feature
Difficulty 3/5 1-2 days Newbie friendliness 52/100
mapbox/mapbox-gl-draw#1636 · 1 comment ·
Maintainers usually reply within 1 day
-
auto-triaged bug
Difficulty 3/5 1-2 days Newbie friendliness 64/100
mapbox/mapbox-gl-draw#1601 · 1 reaction ·
Maintainers usually reply within 1 day
-
auto-triaged bug
Difficulty 2/5 1-3 hours Newbie friendliness 52/100
mapbox/mapbox-gl-draw#1553 · 1 comment ·
Maintainers usually reply within 1 day
-
auto-triaged bug
Difficulty 2/5 1-3 hours Newbie friendliness 30/100
mapbox/mapbox-gl-draw#1540 ·
Maintainers usually reply within 1 day
All issues in mapbox/mapbox-gl-draw
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
521xueweihan/HelloGitHub#4237 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 2 days
-
bug confirmed js v6
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
area/frontend area/v2 kind/bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day