CVE-2026-114143

What it actually does

Repeated string slicing and rejoining of every path prefix during TOML key processing in assign(), deepRef(), and setNestedKey() produces quadratic CPU and memory growth on long dotted keys, table headers, array-of-tables, and inline-table keys; maxDepth does not constrain segment count.

Why it matters to the business

Applications or services that parse untrusted TOML can experience prolonged event-loop blockage or process termination, resulting in denial of service and operational downtime.

How an attack unfolds

An attacker supplies a TOML document containing an extremely long dotted key path to toml.parse(); the parser performs quadratic work on every prefix, exhausting CPU time or memory and halting the Node.js process.

How to fix it

Upgrade toml-node to version 5.0.1 or later; after upgrade, enforce strict input-size limits on TOML documents before parsing.

How to confirm the fix worked

Inspect package.json or node_modules/toml-node/package.json for version >= 5.0.1; replay a long dotted-key TOML payload in a test environment and confirm the parse completes without excessive latency or memory growth.

Typical attack path

1. Craft a TOML payload containing a dotted key with thousands of segments
2. Deliver the payload to any code path that invokes toml.parse() on untrusted input
3. Trigger sustained high CPU usage or out-of-memory termination in the Node.js event loop

How to detect it

Search application and Node.js process logs for sudden spikes in CPU or memory usage during TOML parsing; inspect any captured TOML payloads for unusually long dotted keys or repeated path prefixes.

What your security team should do

• Upgrade toml-node to 5.0.1 immediately across all environments
• Add runtime guards that reject TOML documents exceeding a safe key-segment count before calling parse()
• Monitor Node.js processes for sustained high CPU or memory spikes correlated with TOML parsing
• Review all code paths that accept TOML from external or user-controlled sources