CVE-2026-114141

CVE-2026-114141 is a high-severity security vulnerability in toml (npm), affecting versions <= 5.0.0. It is fixed in 5.0.1.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

toml-node: Quadratic-complexity DoS via many array-of-tables headers in toml.parse()

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.

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:

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]

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.

Affected versions

toml (<= 5.0.0)

Security releases

toml → 5.0.1 (npm)

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

Upgrade toml to 5.0.1 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-114141? CVE-2026-114141 is a high-severity security vulnerability in toml (npm), affecting versions <= 5.0.0. It is fixed in 5.0.1.
  2. Which versions of toml are affected by CVE-2026-114141? toml (npm) versions <= 5.0.0 is affected.
  3. Is there a fix for CVE-2026-114141? Yes. CVE-2026-114141 is fixed in 5.0.1. Upgrade to this version or later.
  4. Is CVE-2026-114141 exploitable, and should I be worried? Whether CVE-2026-114141 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
  5. What actually determines whether CVE-2026-114141 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.
  6. How do I fix CVE-2026-114141? Upgrade toml to 5.0.1 or later.

Other vulnerabilities in toml

Stop the waste.
Protect your environment with Kodem.