GHSA-4qx8-w7c3-pj3p toml-node: Quadratic-complexity DoS via many array-of-tables headers in toml.parse()

• npm toml: < 5.0.1 → fixed in 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: ```js 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: ```js const toml = require('toml'); function distinctArrayHeaders(n) { let out = ''; for (let i = 0; i >` keyed by the first key component) so `addTableArray()` only ever scans the bucket relevant to the path being reopened, in time proportional to that bucket's size rather than the whole document's accumulated path count: ```js var assignedByRoot = new Map(); // root segment -> Set function addTableArray(node) { var path = node.value; var root = path[0]; var bucket = assignedByRoot.get(root) || new Set(); bucket.forEach(function(p) { if (isSameOrSubPath(p, quotedPath)) bucket.delete(p); }); // ...rest of addTableArray unchanged, reading/writing the per-root bucket // instead of the global assignedPaths/valueAssignments Sets } ``` As with the sibling finding, an input-size or table-count limit would also help as defense-in-depth. Credit Discovered and reported by SecDim Security Research secdim.com | @secdim | [email protected]