CVE-2026-49293: js-toml TOML Parser CPU Exhaustion DoS (v1.1.0 and earlier)

Technical summary

The vulnerability stems from a hand-written `parseBigInt` loop in the lexer that processes integer literals in different bases. For each digit consumed, the parser multiplies a BigInt accumulator by the radix, and because BigInt multiplication cost grows with operand size, the total work is O(n²) relative to the number of digits. The lexer regex imposes no length limit on numeric literals, allowing attackers to craft documents with arbitrarily large hex/octal/binary integers. Testing shows a ~500 KB hexadecimal literal consumes ~40 seconds of CPU on modern hardware (M-series Apple machines, Node.js v22). The quadratic amplification means doubling input length quadruples execution time, making this a severe CPU exhaustion vector.

Business impact

Applications that accept TOML from untrusted sources face single-request denial of service. This threatens configuration management systems, CI/CD pipelines that ingest third-party TOML files, IDE plugins parsing user-supplied configs, and build tools. An attacker needs only to submit or commit one malicious TOML file to exhaust a worker process, potentially disrupting deployments, blocking builds, or overloading shared infrastructure. The low barrier to exploitation—no authentication required, no user interaction—makes this a practical attack.

Affected systems

The js-toml library (sunnyadn/js-toml), versions up to and including 1.1.0, is affected. Any JavaScript/Node.js application using this library to parse untrusted TOML is vulnerable. Specifically at risk: web services with TOML config upload endpoints, CI/CD systems that consume TOML from dependencies or pull requests, development tools that parse TOML specifications, and any build or automation framework relying on js-toml.

Exploitability

Exploitability is very high. The attack requires no authentication, no special privileges, and no user interaction—only the ability to submit or influence a TOML document that the target application will parse. The malicious payload is trivial to craft (a long hex number), making weaponization straightforward. Any publicly exposed TOML parsing endpoint or any CI/CD system that auto-ingests third-party TOML is immediately vulnerable.

Remediation

Upgrade js-toml to version 1.1.1 or later, which replaces the vulnerable loop with an efficient algorithm. For applications unable to upgrade immediately, consider implementing a timeout on TOML parsing operations or validating numeric literal length before parsing. If feasible, restrict TOML uploads to authenticated users or pre-approved sources.

Patch guidance

Update the js-toml dependency to version 1.1.1 as specified by the vendor. Verify the fix by checking the package version in your package.json and running `npm list js-toml` (or equivalent for your package manager). Test your TOML parsing workflows after upgrade to ensure no regressions. If using a bundler or monorepo, confirm all transitive dependencies on js-toml receive the update.

Detection guidance

Monitor for sudden CPU spikes during TOML parsing, especially if correlated with uploads or configuration ingestion events. Review logs for large TOML files or unusual numeric literals. In CI/CD environments, flag builds that trigger unexpected CPU exhaustion. Network-level detection is difficult since the payload is valid TOML syntax; focus on runtime behavior (CPU usage, response time) and application logging around parse operations.

Why prioritize this

This vulnerability merits urgent patching due to its high CVSS score (7.5), low attack complexity, and the ease with which untrusted TOML sources are encountered in modern development workflows. The quadratic CPU amplification makes it a potent denial of service weapon, and many organizations use TOML in configuration management and CI/CD without strict input validation. Businesses that cannot immediately patch should implement temporary controls (timeouts, rate limiting) to reduce exposure.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects a network-accessible vulnerability with no authentication required and high availability impact. Although there is no confidentiality or integrity breach, the ability to remotely exhaust CPU resources on a single request justifies the elevated score. The quadratic nature of the attack amplification—not fully captured by CVSS—makes real-world impact potentially more severe than the numeric score suggests.

Frequently asked questions