Key points
- npm toml versions up to 5.0.0 are vulnerable to CPU exhaustion via long integer literals.
- Version 5.0.1 patches the issue by bounding digit sequence length before conversion.
- No authentication is required to exploit this flaw in applications parsing TOML.
The npm `toml` package versions 5.0.0 and earlier contain a high-severity flaw identified as CVE-2026-114144. The vulnerability allows an attacker to cause a denial of service by forcing a Node.js process to consume excessive CPU resources. A fix is available in version 5.0.1. Applications that parse TOML files from untrusted sources should update immediately to mitigate the risk of service disruption.
In plain English
The `toml.parse()` function converts integer values into BigInt objects without checking how long the number string is. Because converting very long numeric strings takes disproportionate time, a single small file with one long number can freeze the application. This happens even if the file is otherwise valid TOML. The process becomes unresponsive while the conversion runs, effectively denying service to legitimate users.
The background
According to GitHub advisory GHSA-9qmh-m7c6-f92p, the parser calls `BigInt()` directly on matched digit text in `lib/parser.js`. This occurs for hex, octal, binary, and decimal formats. While the parser limits structural nesting depth to prevent stack overflows, it does not limit scalar token length. A subsequent range check in `lib/compiler.js` rejects out-of-range values, but only after the expensive conversion has already consumed CPU time.
What changes now
Version 5.0.1 of the `toml` package addresses this vulnerability by implementing bounds on digit sequence length before the BigInt conversion occurs. This prevents the super-linear time complexity issue from impacting the event loop. Users must upgrade their project dependencies to this patched version to resolve the exposure. No other code changes are required within the application itself to benefit from this security fix.
Who needs to act first
Teams should prioritize updating systems that accept TOML input from external users or third-party services. Before rolling out the update, verify compatibility in a test environment to ensure no breaking changes affect existing logic. Back up current configurations and dependencies. If immediate updating is impossible, consider restricting input size at the network or application gateway level to reduce exposure to large payloads.
What to do and how to stay safe: npm
- Update the `toml` package to version 5.0.1 or later in all affected projects.
- Audit applications to identify where TOML parsing occurs, especially with user-supplied data.
- Monitor server CPU usage for spikes that may indicate exploitation attempts.
- Implement input size limits at the web server or API gateway level as a temporary mitigation.
Step-by-step guide: Emergency Patching: How to Fix Critical Flaws Without Breaking Systems
General security guidance from the Patch Review newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of npm toml are vulnerable?
Versions 5.0.0 and earlier are vulnerable to this denial-of-service flaw.
Is there a fix available?
Yes, version 5.0.1 patches the vulnerability by bounding digit sequence length.
Does the attacker need authentication?
No, the advisory states that no authentication or complex crafting is required.
