CVE-2026-129114 in JSON::XS
Summary
by MITRE • 11/14/2026
JSON::XS versions from 3.04 before 4.05 for Perl write one byte past a heap buffer when appending a one-byte chunk in incr_parse.
The incremental buffer grows to one and a half times the length it must hold, with no room reserved for the terminating NUL. For an empty buffer and a one-byte chunk that request is one byte, which a buffer whose front was removed by earlier decodes can already have, so nothing is reallocated and the NUL lands one byte past the allocation.
A peer streaming data to an incr_parse consumer, choosing how the input is split into reads, can cause a one-byte heap out-of-bounds write.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/15/2026
The vulnerability identified in JSON::XS versions ranging from 3.04 up to but not including 4.05 represents a critical memory safety flaw within the Perl programming language ecosystem. This specific issue manifests as an off-by-one error during heap buffer operations, specifically triggered when processing incremental data streams through the incr_parse function. The core technical deficiency lies in how the library manages dynamic memory allocation for its internal parsing buffers. When the parser receives input chunks incrementally, it attempts to resize the buffer to accommodate new data. However, the resizing logic calculates a capacity that is one and a half times the required length but fails to account for the null terminator byte necessary for C-style string operations or safe boundary checks within the underlying implementation. This miscalculation results in an allocation that is exactly one byte too small when specific conditions are met, leading directly to a heap-based buffer overflow.
The operational mechanics of this vulnerability rely on precise control over how input data is fragmented and delivered by a peer streaming data to the consumer application. The flaw becomes exploitable primarily under two concurrent conditions: first, the internal buffer must be in an empty state or have had its front portion removed due previous decode operations, effectively leaving it with minimal allocated space; second, the incoming chunk of JSON data being processed must consist of exactly one byte. In this scenario, the parser requests a resize to hold that single byte plus potentially some overhead for growth factors. Because the calculation does not reserve space for the terminating NUL character, and because no reallocation occurs if the existing buffer size is deemed sufficient by flawed logic, the write operation places data beyond the allocated heap boundary. This results in writing one byte past the end of the heap allocation, corrupting adjacent memory structures or metadata managed by the Perl interpreter's allocator.
From a security impact perspective, this off-by-one heap overflow poses significant risks to application stability and potential remote code execution. While overwriting only a single byte might seem limited, it can overwrite critical data such as size fields in adjacent heap chunks, function pointers, or other control structures depending on the memory layout at runtime. An attacker who controls the input stream could potentially manipulate these overwritten bytes to alter program flow, cause denial of service through segmentation faults, or achieve arbitrary code execution if they can predict and exploit the specific memory state. This type of vulnerability is particularly dangerous in network-facing services that parse JSON data from untrusted sources, as it allows for remote exploitation without requiring local access or user interaction beyond sending a crafted HTTP request or API payload.
This flaw aligns with CWE-122, which describes heap-based buffer overflows where the overflow occurs on dynamically allocated memory rather than stack space. It also relates to CWE-787, an out-of-bounds write vulnerability that arises from incorrect boundary checks during array indexing or pointer arithmetic. In terms of attack vectors and techniques, this scenario maps closely to MITRE ATT&CK technique T1203, which covers Exploitation for Client Execution, particularly in contexts where a service processes untrusted input data streams. The incremental parsing nature means the vulnerability is not limited to single large payloads but can be triggered by carefully crafted small fragments of JSON data sent over time or in rapid succession.
Mitigation strategies must prioritize immediate software updates and defensive coding practices. The most effective remediation is upgrading JSON::XS to version 4.05 or later, where this buffer management logic has been corrected to properly allocate space for the null terminator and enforce strict boundary checks during incremental parsing operations. For environments where an upgrade is not immediately feasible, implementing input validation at the network perimeter can help mitigate risk by limiting the size of individual chunks processed or enforcing stricter JSON schema validations before they reach the vulnerable parser module. Additionally, enabling Address Sanitizer (ASan) in development and testing environments can aid in detecting similar memory safety issues early in the software lifecycle. Developers should also consider adopting static analysis tools that specialize in identifying buffer overflow patterns in Perl modules to prevent recurrence of such low-level memory management errors.