toml-node: Quadratic-complexity DoS via many array-of-tables headers in toml.parse()
Exact source revision recorded 24 Oct 2026 13:17:17 UTC. It does not establish the source's current position. Latest evidence.
osv · GHSA-4qx8-w7c3-pj3p
Published## 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 < 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 keys plus one or more array-of-tables sections (e.g. a `[db]` settings block plus a `[[servers]]` list) — is unremarkable, common real-world TOML, not an edge case. No authentication or special access is required; only the ability to get one TOML string parsed by an application using this library. ## Suggested remediation Avoid scanning the entire `assignedPaths`/`valueAssignments` Sets on every `[[name]]` header. Index entries by their top-level path segment (e.g. a `Map<string, Set<string>>` 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<fullPath> 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]
- Source published
- 22 Oct 2026 16:38:44 UTC
- Source modified
- 22 Oct 2026 16:45:03 UTC
- Observed here
- 24 Oct 2026 13:17:17 UTC
- Source terms
- GitHub Advisory Database · CC-BY-4.0
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Publisher rating · HIGH