Summary
xmldom: HTML raw-text closing-tag case mismatch causes output amplification
In HTML mode (text/html), a raw-text element (script, style, textarea, title) whose closing
tag differs in case from its opening tag (e.g. </ScRiPt> for <script>) is mishandled by the
parser, producing quadratic (O(n²)) output growth, a small crafted document parses and serializes
into output orders of magnitude larger, exhausting CPU and memory. A modest input of tens of KB can
therefore cause a denial of service in any service that parses untrusted HTML with xmldom. Only HTML
mode is affected.
Details
The parser calls parseHtmlSpecialContent for each raw-text element in HTML mode, matched viaisHTMLRawTextElement / isHTMLEscapableRawTextElement (so all four types, script, style,textarea, title, are in scope). It searches for the element's closing tag withsource.indexOf('</' + tagName + '>', elStartEnd), a byte-for-byte case-sensitive match. A
mixed-case closing tag never matches, so the search returns -1, and the followingsource.substring(elStartEnd + 1, -1) extracts text backwards from the start of the document
instead of the element's content. The function then returns -1 to the parse loop, which cannot
advance normally and falls back to character-by-character reprocessing. Every raw-text element
re-captures all source text preceding it, so output grows as O(n²) in the number of such elements.
Root Cause
- Case-sensitive close-tag search (
lib/sax.js:549):source.indexOf('</' + tagName + '>', elStartEnd)does not fold case, contrary to the WHATWG HTML RAWTEXT end-tag-name rule. - Unguarded
-1(lib/sax.js:550):source.substring(elStartEnd + 1, elEndStart)runs even
whenelEndStart === -1, extracting text backwards from position 0. - Unstable progression (
lib/sax.js:556): the function returnselEndStart(-1), driving
repeated character-by-character fallback in the parse loop.
Affected Versions
Only the 0.9.x line is affected, the amplification was introduced in 0.9.0-beta.1 whenparseHtmlSpecialContent was refactored, and remains through 0.9.11. The 0.8.x line is not
affected: its older parseHtmlSpecialContent does not amplify, despite sharing the same
case-sensitive indexOf.
Proof of Concept
const { DOMParser, XMLSerializer } = require('@xmldom/xmldom');
const n = 1000;
const payload = '<html><body>' + '<script>x</ScRiPt>'.repeat(n) + '</body></html>';
const doc = new DOMParser().parseFromString(payload, 'text/html');
const out = new XMLSerializer().serializeToString(doc);
console.log(payload.length, out.length, (out.length / payload.length).toFixed(1) + 'x');
// 18026 9037063 501.3x , an 18 KB input yields ~9 MB of output
Output size grows quadratically with the number of case-mismatched raw-text elements:
Repeats | Input len | Output len | Ratio
1 | 44 | 109 | 2.5x
100 | 1826 | 93763 | 51.3x
500 | 9026 | 2268563 | 251.3x
1000 | 18026 | 9037063 | 501.3x
2000 | 36026 | 36074063 | 1001.3x
Proof of Concept from @KarimTantawey (tested with script); the same amplification occurs for style,textarea, and title.
Severity note
The CVSS 4.0 vector scores availability only (VA:H, with VC:N/VI:N): the flaw neither discloses
nor corrupts data, but a small untrusted HTML input (tens of KB) can force output and memory in the
tens to hundreds of MB, enough to exhaust a service's heap or stall its event loop. It is reachable
with no authentication, configuration, or error-handler setup, only that the application parses
untrusted text/html and serializes the result.
Fix Applied
The raw-text closing tag is now matched case-insensitively in HTML raw-text mode (per the WHATWG HTML
RAWTEXT end-tag rule),
and a missing closing tag is handled explicitly, removing the quadratic output amplification. Output
for well-formed input is unchanged. Non-breaking; 0.9.x-only.
Impact
Small attacker payloads can force disproportionate CPU and memory usage in services that
parse and serialize untrusted HTML via xmldom. The quadratic growth means a modest-sized input
(tens of kilobytes) can produce output in the tens or hundreds of megabytes, potentially
exhausting memory or causing timeouts.
The attack only requires HTML mode (text/html MIME type) and mixed-case closing tags for
any of the four raw-text element types. No special configuration or error handler setup is needed.
Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-83612? CVE-2026-83612 is a high-severity uncontrolled resource consumption vulnerability in @xmldom/xmldom (npm), affecting versions >= 0.9.0-beta.1, <= 0.9.11. It is fixed in 0.9.12. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
- Which versions of @xmldom/xmldom are affected by CVE-2026-83612? @xmldom/xmldom (npm) versions >= 0.9.0-beta.1, <= 0.9.11 is affected.
- Is there a fix for CVE-2026-83612? Yes. CVE-2026-83612 is fixed in 0.9.12. Upgrade to this version or later.
- Is CVE-2026-83612 exploitable, and should I be worried? Whether CVE-2026-83612 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-83612 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-83612? Upgrade
@xmldom/xmldomto 0.9.12 or later.