CVE-2026-77465 in toml-node
Summary
by MITRE • 09/03/2026
toml-node is a TOML parser for Node.js and the browser. Prior to 4.2.0, toml.parse() uses a Peggy 5.1.0 generated recursive-descent parser in lib/parser.js whose peg$parsevalue, peg$parsearray, and peg$parseinline_table_entry functions recurse through nested arrays and inline tables without a depth limit. A remote unauthenticated application parsing an attacker-controlled TOML document containing a few thousand nested arrays or inline tables can exhaust the Node.js call stack, raise an unexpected RangeError rather than the parser's SyntaxError, and terminate an unprotected request worker or process. The corresponding grammar source is src/toml.pegjs, where the generated parser must be bounded. This issue is fixed in version 4.2.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in toml-node versions prior to 4.2.0 represents a critical resource exhaustion flaw rooted in the underlying parsing engine architecture. The library utilizes Peggy, specifically version 5.1.0, to generate a recursive-descent parser located within lib/parser.js. Recursive descent parsers operate by calling functions recursively for each nested element in the input structure. In this specific implementation, the core parsing functions peg$parsevalue, peg$parsearray, and peg$parseinline_table_entry are designed to traverse deeply nested data structures without implementing any mechanism to track or limit recursion depth. This architectural oversight means that the parser relies entirely on the host environment's call stack capacity rather than enforcing a logical boundary defined by the application requirements.
When an attacker provides a maliciously crafted TOML document containing thousands of levels of nested arrays or inline tables, the parser initiates a corresponding chain of recursive function calls for each level of nesting. Because there is no depth limit check before entering these functions, the Node.js call stack grows linearly with the input complexity. The default call stack size in Node.js is relatively small compared to memory heap limits, typically allowing only a few thousand frames depending on frame size and environment settings. Consequently, processing such an unbounded structure quickly exceeds this limit, triggering a RangeError exception rather than the expected SyntaxError that would normally indicate malformed or overly complex input syntax.
The operational impact of this vulnerability is significant for any service relying on toml-node to parse user-supplied configuration files or data payloads. In server-side applications using Node.js, such as web servers handling API requests with TOML bodies, an unhandled RangeError can cause the request worker process to crash abruptly. This results in a Denial of Service condition where legitimate users are unable to access services due to the termination of the processing node. Unlike memory-based attacks that consume gigabytes of RAM, this stack exhaustion attack requires minimal resources from the attacker but causes immediate disruption by crashing the application thread or entire process if not properly isolated within worker pools with strict crash recovery mechanisms.
From a classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write in terms of memory corruption concepts, though more accurately it falls under CWE-400: Uncontrolled Resource Consumption because the primary issue is the exhaustion of system resources (call stack space) due to unbounded recursion. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1496: Resource Hijacking, specifically subcategory E2358 which involves exhausting computational resources through algorithmic complexity attacks. The lack of input validation regarding structural depth allows an adversary to leverage simple syntactic structures to achieve disruptive effects without needing complex exploit code or privilege escalation techniques.
Mitigation strategies primarily involve upgrading the library to version 4.2.0 or later, where the developers have implemented bounds checking within the generated parser logic to prevent excessive recursion depths. For environments unable to upgrade immediately, defensive coding practices should be adopted at the application layer. This includes validating TOML input size and complexity before passing it to the parser, potentially using a separate process with strict memory limits for untrusted parsing tasks via Node.js child processes or worker threads. Additionally, implementing global error handlers that catch RangeError exceptions can prevent immediate process termination, allowing the system to log the incident and return an appropriate HTTP 400 Bad Request response instead of crashing, thereby maintaining service availability even when encountering malformed inputs.