CVE-2026-114141

toml-node is a TOML parser for Node.js and the browser. Prior to 5.0.1, the toml.parse() compiler's addTableArray() function in lib/compiler.js rescans the complete assignedPaths and valueAssignments bookkeeping sets for every array-of-tables header. Distinct [[name]] paths are not pruned, so a document with many such headers causes quadratic synchronous work and can block the Node.js event loop, denying service to other operations in the process. This issue is fixed in version 5.0.1.

toml-node is a TOML parser for Node.js and the browser. Prior to 5.0.1, the toml.parse() compiler's addTableArray() function in lib/compiler.js rescans the complete assignedPaths and valueAssignments bookkeeping sets for every array-of-tables header. Distinct [[name]] paths are not pruned, so a document with many such headers causes quadratic synchronous work and can block the Node.js event loop, denying service to other operations in the process. This issue is fixed in version 5.0.1.

Summary

toml.parse() is vulnerable to a quadratic-complexity (O(n²)) denial-of-service via many array-of-tables ([[name]]) headers. addTableArray() in lib/compiler.js rescans two entire bookkeeping Sets on every [[name]] header without pruning unrelated or distinct entries, so a document containing n such headers costs O(n²) compiler work. A ~321KB document of 20,000 distinct-named [[name]] blocks takes ~10.3 seconds to parse — a completely ordinary-looking TOML shape (a flat settings block plus one or more array-of-tables sections), not a contrived edge case. This is a separate, unpatched code path from the previously fixed stack-overflow DoS (GHSA-82x6-q7mm-w9cf) and requires no key nesting or dotted keys at all.

Affected component / version

• Package: toml (npm), repository BinaryMuse/toml-node
• Function: addTableArray() in lib/compiler.js
• Confirmed present in the audited checkout at commit 1b2ac40 (2026-07-16), one commit past the v5.0.0 tag (a changelog-only change) — i.e. present in v5.0.0, the latest release. Not exhaustively verified against every prior release, but the affected function is unrelated to v5.0.0's BigInt/Temporal changes (per CHANGELOG.md), so the defect likely predates that release as well.

Details

toml.parse(input, options) (index.js:5-9) forwards the caller-supplied string to parser.parse() and then compiler.compile() with no length or structural validation. Every [[name]] (array-of-tables) header is routed (reduce(), lib/compiler.js:43) to addTableArray() (lib/compiler.js:218-245), which performs two full linear scans on every call:

assignedPaths.forEach(function(p) {
  if (isSameOrSubPath(p, quotedPath)) assignedPaths.delete(p);
});
valueAssignments.forEach(function(p) {
  if (isSameOrSubPath(p, quotedPath)) valueAssignments.delete(p);
});

(lib/compiler.js:228-233)

assignedPaths and valueAssignments accumulate one entry per top-level key/table/array path ever assigned in the entire document. Each scan prunes only entries matching the currently reopened path via isSameOrSubPath() (lib/compiler.js:319-321: path === prefix || path.indexOf(prefix + ".") === 0); anything else — an unrelated top-level key, or simply a different array-of-tables name — is never removed and is rescanned in full on every subsequent [[name]] header for the rest of the parse. Set.prototype.forEach has no early exit, so this is unconditionally O(current Set size) on every call, giving O(n²) total work for n such headers.

Proof of Concept

The sharpest reproduction needs no unrelated keys at all — just N array-of-tables headers with N distinct names, since nothing is ever pruned when no name repeats:

const toml = require('toml');

function distinctArrayHeaders(n) {
  let out = '';
  for (let i = 0; i < n; i++) out += `[[a${i}]]\nv = 1\n`;
  return out;
}

// ~321 KB input -- takes ~10.3 seconds
toml.parse(distinctArrayHeaders(20000));

Measured timings (Node, direct execution against this repo):

| Variant | n | input size | time | |---|---|---|---| | N distinct-named [[name]] headers, no unrelated keys | 20,000 | 321 KB | 10.3 s | | Same N with all-same-name headers (self-pruning, control) | 20,000 | 240 KB | 78 ms | | M unrelated top-level keys + N same-name [[name]] headers | M=N=32,000 | 906 KB | 42.3 s |

The ~130x gap between the distinct-name and same-name cases at identical N and comparable input size isolates the mechanism precisely: the bug is unbounded Set growth from never-pruned entries, not string length or any other confound. A product-law check (varying M and N independently in the mixed variant) further confirmed genuine O(M·N) complexity.

Impact

Node.js is single-threaded — this synchronous, multi-second-to-tens-of-seconds compile blocks the entire process event loop, standard uncontested Node.js behavior. The triggering document shape — flat top-level config…

toml-node is a TOML parser for Node.js and the browser. Prior to 5.0.1, the toml.parse() compiler's addTableArray() function in lib/compiler.js rescans the complete assignedPaths and valueAssignments bookkeeping sets for every array-of-tables header. Distinct [[name]] paths are not pruned, so a document with many such headers causes quadratic synchronous work and can block the Node.js event loop, denying service to other operations in the process. This issue is fixed in version 5.0.1.

toml-node is a TOML parser for Node.js and the browser. Prior to 5.0.1, the toml.parse() compiler's addTableArray() function in lib/compiler.js rescans the complete assignedPaths and valueAssignments bookkeeping sets for every array-of-tables header. Distinct [[name]] paths are not pruned, so a document with many such headers causes quadratic synchronous work and can block the Node.js event loop, denying service to other operations in the process. This issue is fixed in version 5.0.1.

Summary

toml.parse() is vulnerable to a quadratic-complexity (O(n²)) denial-of-service via many array-of-tables ([[name]]) headers. addTableArray() in lib/compiler.js rescans two entire bookkeeping Sets on every [[name]] header without pruning unrelated or distinct entries, so a document containing n such headers costs O(n²) compiler work. A ~321KB document of 20,000 distinct-named [[name]] blocks takes ~10.3 seconds to parse — a completely ordinary-looking TOML shape (a flat settings block plus one or more array-of-tables sections), not a contrived edge case. This is a separate, unpatched code path from the previously fixed stack-overflow DoS (GHSA-82x6-q7mm-w9cf) and requires no key nesting or dotted keys at all.

Affected component / version

• Package: toml (npm), repository BinaryMuse/toml-node
• Function: addTableArray() in lib/compiler.js
• Confirmed present in the audited checkout at commit 1b2ac40 (2026-07-16), one commit past the v5.0.0 tag (a changelog-only change) — i.e. present in v5.0.0, the latest release. Not exhaustively verified against every prior release, but the affected function is unrelated to v5.0.0's BigInt/Temporal changes (per CHANGELOG.md), so the defect likely predates that release as well.

Details

toml.parse(input, options) (index.js:5-9) forwards the caller-supplied string to parser.parse() and then compiler.compile() with no length or structural validation. Every [[name]] (array-of-tables) header is routed (reduce(), lib/compiler.js:43) to addTableArray() (lib/compiler.js:218-245), which performs two full linear scans on every call:

assignedPaths.forEach(function(p) {
  if (isSameOrSubPath(p, quotedPath)) assignedPaths.delete(p);
});
valueAssignments.forEach(function(p) {
  if (isSameOrSubPath(p, quotedPath)) valueAssignments.delete(p);
});

(lib/compiler.js:228-233)

assignedPaths and valueAssignments accumulate one entry per top-level key/table/array path ever assigned in the entire document. Each scan prunes only entries matching the currently reopened path via isSameOrSubPath() (lib/compiler.js:319-321: path === prefix || path.indexOf(prefix + ".") === 0); anything else — an unrelated top-level key, or simply a different array-of-tables name — is never removed and is rescanned in full on every subsequent [[name]] header for the rest of the parse. Set.prototype.forEach has no early exit, so this is unconditionally O(current Set size) on every call, giving O(n²) total work for n such headers.

Proof of Concept

The sharpest reproduction needs no unrelated keys at all — just N array-of-tables headers with N distinct names, since nothing is ever pruned when no name repeats:

const toml = require('toml');

function distinctArrayHeaders(n) {
  let out = '';
  for (let i = 0; i < n; i++) out += `[[a${i}]]\nv = 1\n`;
  return out;
}

// ~321 KB input -- takes ~10.3 seconds
toml.parse(distinctArrayHeaders(20000));

Measured timings (Node, direct execution against this repo):

| Variant | n | input size | time | |---|---|---|---| | N distinct-named [[name]] headers, no unrelated keys | 20,000 | 321 KB | 10.3 s | | Same N with all-same-name headers (self-pruning, control) | 20,000 | 240 KB | 78 ms | | M unrelated top-level keys + N same-name [[name]] headers | M=N=32,000 | 906 KB | 42.3 s |

The ~130x gap between the distinct-name and same-name cases at identical N and comparable input size isolates the mechanism precisely: the bug is unbounded Set growth from never-pruned entries, not string length or any other confound. A product-law check (varying M and N independently in the mixed variant) further confirmed genuine O(M·N) complexity.

Impact

Node.js is single-threaded — this synchronous, multi-second-to-tens-of-seconds compile blocks the entire process event loop, standard uncontested Node.js behavior. The triggering document shape — flat top-level config…

TuxCare rebuilt toml to address 2 CVEs. Fixed in 3.0.0-tuxcare.2.

TuxCare rebuilt toml to address 3 CVEs. Fixed in 4.3.0-tuxcare.1.

Root has patched CVE-2026-114141 in the toml package for Root:npm. Multiple fixed versions available.