toml-node: Quadratic-complexity DoS via many array-of-tables headers in toml.parse()
CVE-2026-114141 · GHSA-4qx8-w7c3-pj3p · published 22 Oct 2026
How serious is it
- Severity: high, CVSS score 8.7 out of 10.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-114141?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
toml(npm) <= 5.0.0
How to check
- Run
npm ls tomlin your project to see the installed version, including copies pulled in by other packages. - Or paste your lockfile into the checker: it lists every package with a known vulnerability, this one included.
- Or run
npx shippable-dev scan localhost:3000in your project folder. It reads your lockfile and flags this vulnerability along with every other known one.
How to fix
Copies a prompt for Claude Code, Cursor or Codex: it checks your lockfiles for this and upgrades it.
- Upgrade
tomlto 5.0.1 or later, commit the lockfile and redeploy. - If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
## 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 | security@secdim.com
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- github.com/BinaryMuse/toml-node/security/advisories/GHSA-4qx8-w7c3-pj3p
- nvd.nist.gov/vuln/detail/CVE-2026-114141
- github.com/BinaryMuse/toml-node/commit/609c873fffea0a27ebe5b4dd098eed2b3daf3606
- github.com/BinaryMuse/toml-node/releases/tag/v5.0.1
- github.com/advisories/GHSA-4qx8-w7c3-pj3p
- github.com/BinaryMuse/toml-node
Merged from GitHub Advisory Database, OSV. Last updated 25 Oct 2026. All vulnerabilities · RSS · JSON