Skip to content

deps(frontend): update dependency toml to v5 [security] - #8836

Open
flagsmith-engineering[bot] wants to merge 1 commit into
mainfrom
renovate/npm-toml-vulnerability
Open

deps(frontend): update dependency toml to v5 [security]#8836
flagsmith-engineering[bot] wants to merge 1 commit into
mainfrom
renovate/npm-toml-vulnerability

Conversation

@flagsmith-engineering

@flagsmith-engineering flagsmith-engineering Bot commented Oct 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
toml ^4.0.0 → ^5.0.0 age confidence

toml-node: Uncontrolled resource consumption (CPU DoS) via unbounded-length integer literals in toml.parse()

CVE-2026-114144 / GHSA-9qmh-m7c6-f92p

More information

Details

Summary

toml.parse() converts integer literals (hex, octal, binary, and decimal) to BigInt without first bounding the length of the digit sequence. Since BigInt(string) construction from a very long numeric string runs in super-linear time, a single small, well-formed TOML document containing one long integer literal can pin a Node.js process's event loop at 100% CPU for several seconds — a denial of service for any application that parses attacker-supplied or third-party TOML. No authentication or complex crafting is required.

Details

In lib/parser.js, the grammar actions that build integer nodes call BigInt() directly on the matched digit text, with no upper bound on its length:

  • lib/parser.js:326 — hex: BigInt('0x' + stripUnderscores(digits))
  • lib/parser.js:327 — octal: BigInt('0o' + stripUnderscores(digits))
  • lib/parser.js:328 — binary: BigInt('0b' + stripUnderscores(digits))
  • lib/parser.js:329 — decimal: BigInt(stripUnderscores(text))

The parser does enforce a nesting-depth limit (MAX_DEPTH, default 500, lib/parser.js:4343) to guard against stack overflow from deeply nested arrays/inline tables (per GHSA-82x6-q7mm-w9cf). However, that guard only bounds structural nesting — it does not bound the length of a single scalar token.

The subsequent 64-bit range check in lib/compiler.js (reduceInteger, lines 143–150, comparing against INT64_MIN / INT64_MAX defined at lines 3–4) happens after the expensive BigInt() conversion has already completed. It therefore provides no protection against this cost — the CPU time is already spent by the time the value is rejected as out of range.

PoC
const toml = require('toml');

const N = 5_000_000; // ~5 MB request body
const doc = 'x = 0x' + 'f'.repeat(N);

const start = Date.now();
try {
  toml.parse(doc); // eventually throws "outside the 64-bit signed integer range" —
                    // but only after the costly conversion has run
} catch (e) {}

console.log('elapsed:', Date.now() - start, 'ms');

Measured results:

Digits (hex) Approx. payload size Parse time
200,000 ~200 KB 141 ms
400,000 ~400 KB 276 ms
800,000 ~800 KB 685 ms
1,600,000 ~1.6 MB 1,761 ms
5,000,000 ~5 MB 6,061 ms

Growth is clearly super-linear. The same behavior reproduces for plain decimal literals (3,000,000 '9' digits → ~6.3 s).

Impact

Any application that calls toml.parse() on untrusted or third-party input — config upload endpoints, CI/CD tools ingesting user-supplied .toml files, package managers, linters, editors/language servers — is exposed.

During the conversion, the event loop is fully blocked. In a typical single-threaded Node.js server this stalls all concurrent request handling, not just the request containing the malicious payload. A single ~5 MB request is sufficient to cause several seconds of full CPU denial of service.

Suggested fix: Reject digit sequences above a reasonable length before calling BigInt(), analogous to the existing maxDepth option. A 64-bit signed integer requires at most 20 decimal digits or 16 hex digits, so any digit sequence significantly longer than that is guaranteed to fail the existing range check anyway, and can be rejected with a cheap .length comparison instead of paying for the full BigInt conversion.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

toml-node: Quadratic-complexity DoS via long dotted keys or table paths in toml.parse()

CVE-2026-114143 / GHSA-9j65-hcg3-gc64

More information

Details

Summary

toml.parse() is vulnerable to a quadratic-complexity (O(n²)) denial-of-service via a single
long dotted key, table header, or inline-table key. A ~100KB crafted document causes a
multi-second synchronous hang; a ~200KB document crashes the Node.js process outright with an
uncatchable out-of-memory error. This is a separate, unpatched code path from the previously
fixed stack-overflow DoS (GHSA-82x6-q7mm-w9cf) — it requires no array/inline-table nesting at
all, and is confirmed unaffected by the maxDepth option that fixed that earlier issue.

Affected component / version
  • Package: toml (npm), repository BinaryMuse/toml-node
  • Functions: assign(), deepRef(), setNestedKey() 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 functions are
    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.
Inside lib/compiler.js, three separate functions each walk a dotted key's segments in a
for loop and, on every iteration, recompute the full path-prefix string from scratch:

  • assign() (lines 69-107, the sink at line 81): var intermediatePath = makeFullPath(keys.slice(0, i + 1)); — reached for top-level dotted-key assignments like
    a.b.c = 1.
  • deepRef() (lines 247-281, the sink at line 252): the identical pattern via
    pathKey(keys.slice(0, i + 1)) — reached from table headers [a.b.c] and array-of-tables
    [[a.b.c]] via setPath()/addTableArray().
  • setNestedKey() (lines 184-202, the sink at line 187): the identical pattern — reached from
    inline-table dotted keys like t = { a.b.c = 1 }.

keys.slice(0, i + 1) allocates a new array of length i; pathKey()/makeFullPath()
(lines 311-317) then does .map(quoteDottedString).join("."), also O(i). Since this runs on
every one of the n segments of a dotted key, total work is O(1 + 2 + ... + n) = O(n²), not
O(n). The string is computed unconditionally on the happy path (only ever used if an error
is about to be thrown), so there is no early exit that makes this cheap in practice.

No limit exists anywhere on dotted-key segment count: dot_ended_table_key_part+ and
inline_dot_key_part+ in src/toml.pegjs (lines 122, 311) are unbounded + repetitions,
parsed iteratively rather than through the grammar's value rule — so the existing
MAX_DEPTH/maxDepth nesting guard (src/toml.pegjs:141-151, enforced in the generated
lib/parser.js:1022) does not apply to key length at all. We confirmed this directly: setting
options.maxDepth: 1 (the strictest possible value) against a 16,000-segment key produced no
measurable timing difference from the unrestricted case.

Proof of Concept
const toml = require('toml');

// n-segment dotted key: "k0.k1.k2. ... .k{n-1} = 1"
function segKey(n) {
  const parts = [];
  for (let i = 0; i < n; i++) parts.push('k' + i);
  return parts.join('.') + ' = 1\n';
}

// ~100.9 KB input -- takes ~6.6-6.8 seconds
toml.parse(segKey(16000));

// ~200 KB input -- crashes the Node process:
// "FATAL ERROR: Ineffective mark-compacts near heap limit - JavaScript heap out of memory"
toml.parse(segKey(32000));

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

n (segments) input size time
1,000 ~4.9 KB 34 ms
8,000 ~46.9 KB 1.6 s
16,000 ~100.9 KB 6.8 s
32,000 ~200 KB process crash (OOM)

Doubling n from 8,000→16,000 roughly quadruples runtime (~4.2x), the signature of O(n²)
rather than the expected O(n) (~2x). Independently reproduced with the identical scaling
signature for the table-header variant ([k0. ... .k15999], exercising deepRef()) and the
inline-table variant (t = { k0. ... .k15999 = 1 }, exercising setNestedKey()).

We also generalized this into a property-based fuzzing harness (fast-check, run under Node)
that automatically tests the "doubling input size should not more than roughly double parse
time" invariant across 12 structural dimensions of the grammar/compiler; it independently
re-flags all three code paths above on every run, with no additional dimension confirmed
vulnerable after follow-up investigation. The harness is available on request.

Impact

Node.js is single-threaded — a synchronous multi-second-to-crashing parse() call blocks the
entire event loop of the process calling it, stalling every other request/operation that
process is handling, not just the attacker's own. At the upper end this is not merely a hang:
an uncaught, process-terminating out-of-memory crash from a ~200KB attacker-supplied string is
a full denial of service requiring no authentication — just the ability to get one string
parsed by an application using this library (config upload, API request body, imported
manifest, or any of this library's intended use cases).

Suggested remediation

Build the path prefix as an incrementally-extended string as the loop walks each segment
(append one already-quoted segment per iteration to a running string) instead of re-slicing an
array and re-joining the entire prefix from scratch on every iteration. For example, in
assign():

function assign(node) {
  var keys = node.key;
  var value = node.value;
  var off = node.offset;
  if (!Array.isArray(keys)) keys = [keys];
  var reduced = reduceValueNode(value);

  var target = context;
  var pathStr = pathKey(currentPath); // computed once, not per segment
  for (var i = 0; i < keys.length - 1; i++) {
    var k = keys[i];
    var quotedK = quoteDottedString(k);
    var intermediatePath = pathStr ? pathStr + "." + quotedK : quotedK; // O(new segment), not O(i)
    pathStr = intermediatePath;
    // ...same conditional logic as today, using intermediatePath
    target = target[k];
  }
  // ...
}

The identical treatment applies to deepRef() and setNestedKey(). As defense-in-depth,
consider also capping total key-segment count or overall input size, the same way maxDepth
already caps nesting.

Credit

Discovered and reported by SecDim Security Research
secdim.com | @​secdim | security@secdim.com

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: 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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-114141 / GHSA-4qx8-w7c3-pj3p

More information

Details

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 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:

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

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: 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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-114141 / GHSA-4qx8-w7c3-pj3p

More information

Details

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 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:

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

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: 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

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

toml-node: Quadratic-complexity DoS via long dotted keys or table paths in toml.parse()

CVE-2026-114143 / GHSA-9j65-hcg3-gc64

More information

Details

Summary

toml.parse() is vulnerable to a quadratic-complexity (O(n²)) denial-of-service via a single
long dotted key, table header, or inline-table key. A ~100KB crafted document causes a
multi-second synchronous hang; a ~200KB document crashes the Node.js process outright with an
uncatchable out-of-memory error. This is a separate, unpatched code path from the previously
fixed stack-overflow DoS (GHSA-82x6-q7mm-w9cf) — it requires no array/inline-table nesting at
all, and is confirmed unaffected by the maxDepth option that fixed that earlier issue.

Affected component / version
  • Package: toml (npm), repository BinaryMuse/toml-node
  • Functions: assign(), deepRef(), setNestedKey() 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 functions are
    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.
Inside lib/compiler.js, three separate functions each walk a dotted key's segments in a
for loop and, on every iteration, recompute the full path-prefix string from scratch:

  • assign() (lines 69-107, the sink at line 81): var intermediatePath = makeFullPath(keys.slice(0, i + 1)); — reached for top-level dotted-key assignments like
    a.b.c = 1.
  • deepRef() (lines 247-281, the sink at line 252): the identical pattern via
    pathKey(keys.slice(0, i + 1)) — reached from table headers [a.b.c] and array-of-tables
    [[a.b.c]] via setPath()/addTableArray().
  • setNestedKey() (lines 184-202, the sink at line 187): the identical pattern — reached from
    inline-table dotted keys like t = { a.b.c = 1 }.

keys.slice(0, i + 1) allocates a new array of length i; pathKey()/makeFullPath()
(lines 311-317) then does .map(quoteDottedString).join("."), also O(i). Since this runs on
every one of the n segments of a dotted key, total work is O(1 + 2 + ... + n) = O(n²), not
O(n). The string is computed unconditionally on the happy path (only ever used if an error
is about to be thrown), so there is no early exit that makes this cheap in practice.

No limit exists anywhere on dotted-key segment count: dot_ended_table_key_part+ and
inline_dot_key_part+ in src/toml.pegjs (lines 122, 311) are unbounded + repetitions,
parsed iteratively rather than through the grammar's value rule — so the existing
MAX_DEPTH/maxDepth nesting guard (src/toml.pegjs:141-151, enforced in the generated
lib/parser.js:1022) does not apply to key length at all. We confirmed this directly: setting
options.maxDepth: 1 (the strictest possible value) against a 16,000-segment key produced no
measurable timing difference from the unrestricted case.

Proof of Concept
const toml = require('toml');

// n-segment dotted key: "k0.k1.k2. ... .k{n-1} = 1"
function segKey(n) {
  const parts = [];
  for (let i = 0; i < n; i++) parts.push('k' + i);
  return parts.join('.') + ' = 1\n';
}

// ~100.9 KB input -- takes ~6.6-6.8 seconds
toml.parse(segKey(16000));

// ~200 KB input -- crashes the Node process:
// "FATAL ERROR: Ineffective mark-compacts near heap limit - JavaScript heap out of memory"
toml.parse(segKey(32000));

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

n (segments) input size time
1,000 ~4.9 KB 34 ms
8,000 ~46.9 KB 1.6 s
16,000 ~100.9 KB 6.8 s
32,000 ~200 KB process crash (OOM)

Doubling n from 8,000→16,000 roughly quadruples runtime (~4.2x), the signature of O(n²)
rather than the expected O(n) (~2x). Independently reproduced with the identical scaling
signature for the table-header variant ([k0. ... .k15999], exercising deepRef()) and the
inline-table variant (t = { k0. ... .k15999 = 1 }, exercising setNestedKey()).

We also generalized this into a property-based fuzzing harness (fast-check, run under Node)
that automatically tests the "doubling input size should not more than roughly double parse
time" invariant across 12 structural dimensions of the grammar/compiler; it independently
re-flags all three code paths above on every run, with no additional dimension confirmed
vulnerable after follow-up investigation. The harness is available on request.

Impact

Node.js is single-threaded — a synchronous multi-second-to-crashing parse() call blocks the
entire event loop of the process calling it, stalling every other request/operation that
process is handling, not just the attacker's own. At the upper end this is not merely a hang:
an uncaught, process-terminating out-of-memory crash from a ~200KB attacker-supplied string is
a full denial of service requiring no authentication — just the ability to get one string
parsed by an application using this library (config upload, API request body, imported
manifest, or any of this library's intended use cases).

Suggested remediation

Build the path prefix as an incrementally-extended string as the loop walks each segment
(append one already-quoted segment per iteration to a running string) instead of re-slicing an
array and re-joining the entire prefix from scratch on every iteration. For example, in
assign():

function assign(node) {
  var keys = node.key;
  var value = node.value;
  var off = node.offset;
  if (!Array.isArray(keys)) keys = [keys];
  var reduced = reduceValueNode(value);

  var target = context;
  var pathStr = pathKey(currentPath); // computed once, not per segment
  for (var i = 0; i < keys.length - 1; i++) {
    var k = keys[i];
    var quotedK = quoteDottedString(k);
    var intermediatePath = pathStr ? pathStr + "." + quotedK : quotedK; // O(new segment), not O(i)
    pathStr = intermediatePath;
    // ...same conditional logic as today, using intermediatePath
    target = target[k];
  }
  // ...
}

The identical treatment applies to deepRef() and setNestedKey(). As defense-in-depth,
consider also capping total key-segment count or overall input size, the same way maxDepth
already caps nesting.

Credit

Discovered and reported by SecDim Security Research
secdim.com | @​secdim | security@secdim.com

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: 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

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

toml-node: Uncontrolled resource consumption (CPU DoS) via unbounded-length integer literals in toml.parse()

CVE-2026-114144 / GHSA-9qmh-m7c6-f92p

More information

Details

Summary

toml.parse() converts integer literals (hex, octal, binary, and decimal) to BigInt without first bounding the length of the digit sequence. Since BigInt(string) construction from a very long numeric string runs in super-linear time, a single small, well-formed TOML document containing one long integer literal can pin a Node.js process's event loop at 100% CPU for several seconds — a denial of service for any application that parses attacker-supplied or third-party TOML. No authentication or complex crafting is required.

Details

In lib/parser.js, the grammar actions that build integer nodes call BigInt() directly on the matched digit text, with no upper bound on its length:

  • lib/parser.js:326 — hex: BigInt('0x' + stripUnderscores(digits))
  • lib/parser.js:327 — octal: BigInt('0o' + stripUnderscores(digits))
  • lib/parser.js:328 — binary: BigInt('0b' + stripUnderscores(digits))
  • lib/parser.js:329 — decimal: BigInt(stripUnderscores(text))

The parser does enforce a nesting-depth limit (MAX_DEPTH, default 500, lib/parser.js:4343) to guard against stack overflow from deeply nested arrays/inline tables (per GHSA-82x6-q7mm-w9cf). However, that guard only bounds structural nesting — it does not bound the length of a single scalar token.

The subsequent 64-bit range check in lib/compiler.js (reduceInteger, lines 143–150, comparing against INT64_MIN / INT64_MAX defined at lines 3–4) happens after the expensive BigInt() conversion has already completed. It therefore provides no protection against this cost — the CPU time is already spent by the time the value is rejected as out of range.

PoC
const toml = require('toml');

const N = 5_000_000; // ~5 MB request body
const doc = 'x = 0x' + 'f'.repeat(N);

const start = Date.now();
try {
  toml.parse(doc); // eventually throws "outside the 64-bit signed integer range" —
                    // but only after the costly conversion has run
} catch (e) {}

console.log('elapsed:', Date.now() - start, 'ms');

Measured results:

Digits (hex) Approx. payload size Parse time
200,000 ~200 KB 141 ms
400,000 ~400 KB 276 ms
800,000 ~800 KB 685 ms
1,600,000 ~1.6 MB 1,761 ms
5,000,000 ~5 MB 6,061 ms

Growth is clearly super-linear. The same behavior reproduces for plain decimal literals (3,000,000 '9' digits → ~6.3 s).

Impact

Any application that calls toml.parse() on untrusted or third-party input — config upload endpoints, CI/CD tools ingesting user-supplied .toml files, package managers, linters, editors/language servers — is exposed.

During the conversion, the event loop is fully blocked. In a typical single-threaded Node.js server this stalls all concurrent request handling, not just the request containing the malicious payload. A single ~5 MB request is sufficient to cause several seconds of full CPU denial of service.

Suggested fix: Reject digit sequences above a reasonable length before calling BigInt(), analogous to the existing maxDepth option. A 64-bit signed integer requires at most 20 decimal digits or 16 hex digits, so any digit sequence significantly longer than that is guaranteed to fail the existing range check anyway, and can be rejected with a cheap .length comparison instead of paying for the full BigInt conversion.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

toml-node: Prototype pollution: parsing a TOML document can write to Object.prototype

CVE-2026-114142 / GHSA-h895-cgqg-jf52

More information

Details

Summary

CVE-2026-63376 described prototype pollution through proto key-path desynchronization and was fixed in 4.1.2 by rewriting the path bookkeeping and adding an ownedContainers WeakSet. The desynchronization is still reachable, spelled with a quote character instead of a dot, and the owned-container check is not applied on the path that matters.

A four-line TOML document parsed with toml.parse() writes a property onto Object.prototype, where it is visible to every object in the process — including objects produced by unrelated libraries.

Details

Three gaps compose. All line numbers are lib/compiler.js in 5.0.0.

1. The path-key encoding is ambiguous. quoteDottedString() quotes a segment only when it contains a ., and never escapes a " inside the segment:

287:  function quoteDottedString(str) {
288:    if (str.indexOf(".") > -1) {
289:      return "\"" + str + "\"";
290:    } else {
291:      return str;
292:    }
293:  }

So the key path ['x.y'] and the key path ['"x', 'y"'] both render as the string "x.y". This is the same desynchronization CVE-2026-63376 named, with a quote in place of the dot.

2. A table-array header can clear another key's guard. addTableArray() walks assignedPaths / valueAssignments with isSameOrSubPath() over those ambiguous strings, so a header whose rendered path collides with an unrelated key deletes that key's entry.

3. The descent in assign() has no owned-container check. deepRef() applies isOwnedContainer() only to intermediate segments (lib/compiler.js:265, :273) and returns the final container unchecked. assign() then walks it with only a shape test:

 93:      target = target[k];
...
103:    target[lastKey] = reduced;

A TOML datetime is a Date. It satisfies typeof target[k] === "object" and is not an array, so the walk descends into it — and a Date has a live prototype chain to Object.prototype.

Putting the three together, a document can make the current table a Date and then walk __proto__.__proto__ to Object.prototype.

mkdir poc && cd poc && npm init -y >/dev/null && npm install toml@5.0.0
##### poc.toml
"b.c" = 1979-05-27T07:32:00Z
[['"b']]
["b.c"]
__proto__.__proto__.polluted = "yes"

Line 1 defines a key whose rendered path is "b.c" and whose value is a Date.
Line 2 is a table-array header whose rendered path collides with it, clearing its guard.
Line 3 re-enters that key, so the current table is now the Date.
Line 4 walks Date → Date.prototype → Object.prototype.

// poc.js
const toml = require('toml');
const fs = require('fs');

console.log('before:', JSON.stringify(({}).polluted));
toml.parse(fs.readFileSync('poc.toml', 'utf8'));
console.log('after: ', JSON.stringify(({}).polluted));
console.log('Object.prototype.hasOwnProperty("polluted") =', Object.prototype.hasOwnProperty('polluted'));
console.log('JSON.parse("{}").polluted =', JSON.stringify(JSON.parse('{}').polluted));
$ node poc.js
before: undefined
after:  "yes"
Object.prototype.hasOwnProperty("polluted") = true
JSON.parse("{}").polluted = "yes"

The payload sets a single harmless marker property. The last line shows the property is visible on an object this code never touched.

A useful control: the same document without line 2 (the guard-clearing header) is correctly rejected on 4.1.2 and later, which confirms the clearing step is what is load-bearing.

Impact

Any application that parses a TOML document from an untrusted source is affected — a configuration file uploaded by a user, a manifest from a third-party package or repository, a document posted to an API. Prototype pollution of this kind commonly escalates to authentication or authorization bypass, denial of service, and in applications with a suitable gadget, remote code execution, because every object in the process inherits the injected property.

Suggested fix: in assign(), apply the same check the intermediate descent already uses — after target = target[k], reject when !isOwnedContainer(target). Equivalently, apply isOwnedContainer to the value deepRef() returns. Separately, quoteDottedString() should escape " inside a segment so that distinct key paths cannot render to the same string.

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

BinaryMuse/toml-node (toml)

v5.0.1

Compare Source

=======================

  • Address four security advisories, each reachable by parsing untrusted input:
    • CVE-2026-114142, in which a crafted document could still write to Object.prototype. Two distinct key paths could render to the same bookkeeping string, letting an array-of-tables header clear the guard on an unrelated key, after which a dotted key could descend through a date value into its prototype chain. The compiler now records how each table was defined on the table itself rather than in string-keyed sets, so paths cannot collide and key paths can only descend through tables the compiler created.
    • CVE-2026-114143, in which dotted keys, table headers, and inline-table keys with many segments took quadratic time to resolve.
    • CVE-2026-114141, in which every array-of-tables header rescanned all paths defined so far, so documents with many such headers took quadratic time.
    • CVE-2026-114144, in which integer literals were converted to BigInt before any size check, so a multi-megabyte literal consumed super-linear CPU time before being rejected. Literals with more digits than any 64-bit integer are now rejected before conversion.

v5.0.0

Compare Source

=====================

  • Breaking: Integers outside JavaScript's safe range (beyond ±Number.MAX_SAFE_INTEGER) now throw a parse error instead of silently returning a rounded value (#​28). Opt in to lossless handling of the full 64-bit range with toml.parse(input, { bigint: true }), which returns all integer values as BigInt.
  • Breaking: Integers outside TOML's 64-bit signed integer range now throw a parse error in either mode, as required by the spec. Previously they were silently rounded.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

@flagsmith-engineering
flagsmith-engineering Bot requested a review from a team as a code owner October 23, 2026 03:21
@vercel

vercel Bot commented Oct 23, 2026 •
edited
Loading

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
flagsmith-frontend-preview Ready Ready Preview Oct 23, 2026 3:22am UTC
flagsmith-frontend-staging Ready Ready Preview Oct 23, 2026 3:22am UTC
1 Skipped Deployment
Project Deployment Actions Updated
docs Ignored Ignored Preview Oct 23, 2026 3:22am UTC

Request Review

@flagsmith-engineering flagsmith-engineering Bot added dependencies Pull requests that update a dependency file front-end Issue related to the React Front End Dashboard labels Oct 23, 2026
@flagsmith-engineering
flagsmith-engineering Bot requested review from talissoncosta and removed request for a team October 23, 2026 03:21
@coderabbitai

coderabbitai Bot commented Oct 23, 2026

Copy link
Copy Markdown

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: ASSERTIVE
  • Plan: Advanced
  • Run ID: 6c63f19f-b2db-493e-9a89-e9b4d00e55e6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

github-actions Bot commented Oct 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor
✅ oss · depot-ubuntu-latest-arm-16 — run #22664 (attempt 1)

Playwright Test Results (oss - depot-ubuntu-latest-arm-16)

passed  2 passed

Details

stats  2 tests across 2 suites
duration  36.1 seconds
commit  bbf6d61
info  🔄 Run: #22664 (attempt 1)

🗂️ Previous results
✅ oss · depot-ubuntu-latest-16 — run #22664 (attempt 1)

Playwright Test Results (oss - depot-ubuntu-latest-16)

passed  1 passed

Details

stats  1 test across 1 suite
duration  32.4 seconds
commit  bbf6d61
info  🔄 Run: #22664 (attempt 1)

This branch was successfully deployed

2 active deployments
Preview – flagsmith-frontend-preview — bbf6d612 Deployed Oct 23, 2026 by vercel[bot]
View deployment
Preview – flagsmith-frontend-staging — bbf6d612 Deployed Oct 23, 2026 by vercel[bot]
View deployment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@talissoncosta talissoncosta Awaiting requested review from talissoncosta talissoncosta is a code owner automatically assigned from Flagsmith/flagsmith-front-end

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file front-end Issue related to the React Front End Dashboard

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants