CVE-2026-129113 in JSON::XS
Summary
by MITRE • 11/14/2026
JSON::XS versions from 4.0_00 before 4.05 for Perl corrupt the incremental buffer length by chopping past its end in incr_skip after a top-level number.
The incremental parser scans any run of digits, signs, dots and exponent markers as one number, but the decoder stops at the end of a valid number, so the parser keeps an offset into bytes it has not decoded. It then empties the buffer without clearing those bytes, and a later incr_parse call without new input reads them again and moves the offset past the end of the buffer. incr_skip, the documented recovery after an error, removes that many bytes and the buffer length wraps.
A peer sending input such as "1-2" to an incr_parse consumer can make the next read of incr_text exit the process through perl's uncatchable out-of-memory path.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/14/2026
The vulnerability identified in JSON::XS versions prior to 4.05 represents a critical memory management flaw within the incremental parsing logic, specifically affecting how the library handles buffer boundaries and offset tracking during error recovery scenarios. This issue stems from an inconsistency between the lexical scanning phase of the parser and the actual decoding state machine. When processing input incrementally, the scanner identifies sequences comprising digits, signs, decimal points, and exponent markers as a single numeric entity. However, the decoder component strictly adheres to valid JSON number syntax rules, which may cause it to stop parsing before the full sequence identified by the scanner is consumed if that sequence contains invalid characters for a standalone number context. This discrepancy results in the parser maintaining an internal offset pointing to bytes within the input buffer that have not yet been successfully decoded or processed into Perl data structures.
The core technical flaw manifests when the incremental processing loop empties the current buffer segment without properly resetting or clearing these stale byte references and associated offset counters. Consequently, if a subsequent incr_parse call is invoked with new input but no additional raw bytes are appended to the internal state immediately, the parser attempts to process the residual data from the previous iteration. Because the offset was not cleared, it continues to advance based on the old buffer's length rather than the newly provided or expected boundaries. This leads to a situation where the incremental skip mechanism, incr_skip, which is designed as an error recovery tool to discard malformed input and resume parsing, operates on incorrect assumptions about available data. The function removes bytes from the logical stream but fails to account for the fact that those bytes are no longer present in the active buffer memory space due to prior emptying operations.
This logic error results in a severe integer wraparound or underflow condition within the buffer length tracking variables. As incr_skip attempts to remove more bytes than are actually available in the current buffer context, the internal counter wraps around to an extremely large positive value. This corrupted state directly impacts subsequent memory allocation requests made by Perl's runtime environment when attempting to manage string buffers or parse further input. The system interprets this wrapped-around length as a valid but massive size requirement for memory operations. In practical terms, this triggers perl's uncatchable out-of-memory path, causing the application process to terminate abruptly without generating standard error exceptions that could be caught and handled by higher-level code.
The operational impact of this vulnerability is significant for any service or script utilizing JSON::XS in incremental mode with user-controlled input. An attacker who can supply crafted payloads such as "1-2" demonstrates how a simple sequence containing digits followed by an invalid character like a hyphen can trigger the parsing discrepancy. The scanner sees numbers and signs, but the decoder rejects the combination as an incomplete or invalid number structure depending on context. This mismatch initiates the chain of events leading to buffer corruption. For long-running daemons processing streaming JSON data, this flaw allows for remote denial-of-service attacks with minimal effort from the adversary. There is no need for complex exploitation techniques; simply sending a malformed numeric string can crash the target process by exhausting system memory resources through infinite allocation attempts driven by the corrupted length value.
From a classification perspective, this vulnerability aligns closely with CWE-190 Integer Overflow or Wraparound and CWE-401 Missing Release of Memory after Effective Lifetime if interpreted as a resource leak leading to exhaustion, though the primary mechanism is an integer wrap causing out-of-bounds access logic in Perl's memory manager. It also relates to CWE-20 Improper Input Validation because the parser fails to correctly validate that the consumed input matches the expected structural boundaries before advancing state. In terms of MITRE ATT&CK mapping, this behavior facilitates Denial of Service (T1499) by causing resource exhaustion through a logic error rather than traditional buffer overflow exploitation vectors. The attack vector is typically Network (TA0001) if the service exposes an API accepting JSON payloads, making it remotely exploitable over standard network protocols like HTTP or TCP streams that transmit incremental data chunks.
Mitigation strategies must prioritize upgrading to version 4.05 of JSON::XS where this logic error has been corrected by ensuring buffer offsets are properly synchronized with actual content availability after each parse cycle. Developers relying on older versions should implement strict input validation at the application layer before passing data to the parser, although this is less effective against incremental parsing flaws since the corruption occurs internally during state transitions rather than just in initial acceptance. Implementing timeouts and memory limits within the hosting environment can provide a secondary defense-in-depth measure by preventing any single process from consuming excessive resources even if triggered. Additionally, switching to non-incremental parsing modes where entire payloads are processed atomically may avoid this specific class of buffer management errors entirely, provided that memory constraints for large payloads do not become an issue in their own right. Regular auditing of third-party library versions and applying security patches promptly remains the most effective defense against such logic-based vulnerabilities in widely used serialization libraries.