CVE-2026-49293: js-toml Parser DOS Vulnerability

CVE-2026-49293 Overview

CVE-2026-49293 is a denial-of-service vulnerability in js-toml, a JavaScript TOML parser compliant with the TOML 1.0.0 specification. Versions up to and including 1.1.0 parse hexadecimal, octal, and binary integer literals using a hand-written parseBigInt loop with quadratic time complexity. An attacker who supplies a TOML document containing a single large non-decimal integer literal can pin a CPU core for tens of seconds per request. The lexer regex enforces no upper bound on literal length, so doubling the input quadruples the parsing work. Applications calling load() on attacker-controlled TOML such as configuration upload endpoints, CI/CD systems, IDE plugins, and build tools are exposed [CWE-400]. Version 1.1.1 fixes the issue.

Critical Impact
A single TOML document containing a ~500 kB hex literal pins one CPU core for approximately 40 seconds on a modern laptop, enabling single-request CPU exhaustion against any service that parses untrusted TOML.

Affected Products

js-toml versions up to and including 1.1.0
Applications invoking load() on attacker-controlled TOML input
Build tools, CI/CD pipelines, and IDE plugins ingesting third-party *.toml files

Discovery Timeline

2026-06-19 - CVE-2026-49293 published to NVD
2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-49293

Vulnerability Analysis

The vulnerability resides in the parseBigInt function used by js-toml to interpret non-decimal integer literals. The function iterates over each digit of the literal and multiplies a BigInt accumulator by the radix on every iteration. Because BigInt * BigInt cost grows linearly with the accumulator's digit count, the overall loop runs in O(n²) time relative to literal length. Memory amplification is bounded, but CPU amplification is severe. The CWE-400 classification reflects uncontrolled resource consumption rather than memory exhaustion.

Root Cause

Two design defects combine to produce the issue. First, the lexer regex for hexadecimal, octal, and binary literals places no upper bound on literal length, so the parser will accept arbitrarily long digit sequences. Second, the parseBigInt implementation performs repeated multiplication on a growing accumulator instead of using a balanced or chunked conversion strategy. The result is quadratic work per literal.

Attack Vector

The attack requires only the ability to submit a TOML document to a vulnerable parser. No authentication, user interaction, or local access is needed. Any endpoint that calls load() on untrusted input is exposed, including configuration upload APIs, CI/CD systems consuming third-party *.toml files, IDE plugins, and build tools. A single request containing one large hex, octal, or binary literal is sufficient to exhaust a CPU core.

typescript

// Security patch in src/load/tokens/NonDecimalInteger.ts
// Adds SyntaxParseError import as part of bounding non-decimal integer parsing
 import { hexDigit, underscore } from './patterns.js';
 import { registerTokenInterpreter } from './tokenInterpreters.js';
 import { Integer } from './Integer.js';
+import { SyntaxParseError } from '../exception.js';
 import XRegExp from 'xregexp';
 
 const hexPrefix = /0x/;

Source: GitHub Commit 1abcb31

Detection Methods for CVE-2026-49293

Indicators of Compromise

TOML documents containing hexadecimal (0x...), octal (0o...), or binary (0b...) literals exceeding several kilobytes in length.
Single HTTP requests or file uploads that cause sustained 100% CPU utilization on a single core of a Node.js process.
Repeated parser timeouts or worker-thread terminations correlated with TOML ingestion endpoints.

Detection Strategies

Inventory dependencies for js-toml at versions <= 1.1.0 using npm ls js-toml or software composition analysis tooling.
Instrument calls to load() with timing wrappers and alert when parse duration exceeds a defined threshold.
Inspect inbound TOML payloads for non-decimal integer literals greater than a reasonable size such as 1 kB before invoking the parser.

Monitoring Recommendations

Track per-request CPU time on services that accept TOML input and alert on outliers.
Log payload sizes and structural characteristics for any endpoint invoking js-toml.
Monitor Node.js event-loop lag metrics to identify single-request stalls indicative of algorithmic complexity attacks.

How to Mitigate CVE-2026-49293

Immediate Actions Required

Upgrade js-toml to version 1.1.1 or later across all applications and build pipelines.
Audit every code path that calls load() on untrusted input and gate it behind size limits.
Restrict TOML ingestion endpoints to authenticated users where business requirements permit.

Patch Information

The fix is published in js-toml version 1.1.1. See the GitHub Release v1.1.1, the GitHub Security Advisory GHSA-wp3c-266w-4qfq, and the corrective GitHub Commit 1abcb31.

Workarounds

Enforce a maximum payload size on any endpoint that feeds TOML to load(), ideally well below 100 kB.
Reject or pre-scan documents containing non-decimal integer literals longer than a few hundred characters.
Execute TOML parsing inside a worker thread with a hard timeout so a stalled parse cannot block the main event loop.

bash

# Upgrade js-toml to the patched release
npm install js-toml@1.1.1

# Verify the resolved version
npm ls js-toml