CVE-2026-122126 in reSIProcate
Summary
by MITRE • 11/04/2026
reSIProcate reTurn client through 1.14.0 contains a heap buffer overflow in TurnTcpSocket::handleReadHeader() that allows malicious TURN servers to overwrite memory via oversized frame lengths. Attackers can send STUN or ChannelData frames declaring up to 65535 bytes, writing roughly 57 KB past the fixed 8192-byte mReadBuffer and crashing the client.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in reSIProcate versions through 1.14.0 represents a critical heap buffer overflow within the TURN protocol implementation, specifically located in the TurnTcpSocket::handleReadHeader() function. This flaw arises from an insufficient validation of frame length fields received during the communication process between the client and external servers. The underlying technical defect involves the application's failure to verify that the declared size of incoming STUN or ChannelData frames aligns with the actual capacity of the allocated memory buffer, which is fixed at 8192 bytes for reading operations. When a malicious TURN server sends a frame header indicating a length significantly larger than this limit, such as values approaching the maximum uint16_t value of 65535 bytes, the application proceeds to copy data into the pre-allocated buffer without bounds checking. This results in writing approximately 57 kilobytes past the end of the allocated heap memory region, corrupting adjacent memory structures and leading to immediate instability or termination of the client process.
From a technical perspective, this issue is classified under CWE-120, which denotes Buffer Overflow without explicit mention of bounds checking, and more specifically aligns with CWE-787 in contexts where out-of-bounds writes occur on heap-allocated memory. The exploitation vector relies heavily on the trust placed in network peers within the Session Traversal Utilities for NAT (STUN) and TURN ecosystem. By crafting a malicious packet that declares an oversized frame length, an attacker can trigger this overflow condition remotely over TCP connections. The operational impact of such a vulnerability is severe, primarily manifesting as a denial-of-service scenario where the client application crashes due to memory corruption. However, depending on the specific heap layout and operating system protections in place at the time of exploitation, there may also be potential for arbitrary code execution if an attacker can precisely control the data written beyond the buffer boundary to overwrite function pointers or object vtables, although the primary observed effect is a crash.
In terms of threat modeling, this vulnerability maps directly to MITRE ATT&CK technique T1498.002, Network Denial of Service via Resource Exhaustion by Application Layer Protocol Abuse. The attacker leverages the protocol's parsing logic against itself, forcing the application into an invalid state through malformed input rather than overwhelming it with volume alone. This type of attack is particularly dangerous in environments where reSIProcate clients are used for real-time communication services, as a crash can disrupt ongoing sessions and degrade user experience significantly. The lack of proper validation at the header parsing stage highlights a common oversight in network service development where maximum packet sizes are not strictly enforced against internal buffer constraints before data ingestion begins.
Mitigation strategies must focus on immediate patching to version 1.14.0 or later, which addresses this specific bounds-checking deficiency within the handleReadHeader() method. For organizations unable to upgrade immediately, network-level controls such as deep packet inspection firewalls can be configured to drop TURN packets with frame lengths exceeding reasonable thresholds for standard media streams, effectively neutralizing the exploit vector before it reaches the vulnerable application layer. Additionally, developers should implement strict input validation routines that compare declared payload sizes against available buffer space prior to any memory copy operations. Enabling heap protection mechanisms like ASLR and DEP on client systems can also reduce the likelihood of successful exploitation for code execution scenarios, although these measures do not prevent the denial-of-service impact caused by the crash itself. Regular security audits focusing on network protocol parsers are essential to identify similar discrepancies between declared data sizes and allocated memory regions in other components of the software stack.