CVE-2026-75538 in OTP
Summary
by MITRE • 09/01/2026
An attacker that connects to an open Erlang TCP port that uses the inet driver with {packet,4} mode can use a signed overflow in an incorrect packet length calculation to overflow the receive buffer into the VM allocator area and beyond up to about 2 GB.
This would easily trash the allocated block's allocator metadata footer, and the next block, if any, and most likely cause the BEAM VM to crash. Utilizing this with precision enough to achieve Remote Code Execution would be extremely unfeasible.
This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to erts from 6.0 before 15.2.7.13, from 16.0 before 16.4.0.6, and from 17.0 before 17.0.6. Whether OTP before OTP 17.0, corresponding to erts before 6.0, is affected is unknown.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability described involves a critical integer overflow within the Erlang/OTP runtime system, specifically affecting the inet driver when operating in packet mode four. This configuration expects fixed-length packets of exactly four bytes for length specification, which is common in many binary protocol implementations. The core technical flaw lies in how the VM calculates and validates the size of incoming data buffers based on these headers. An attacker who can establish a connection to an open Erlang TCP port exploits this logic by sending crafted packet lengths that trigger a signed integer overflow during the calculation phase. This miscalculation results in the system allocating or attempting to access memory regions far larger than intended, leading to a buffer overflow condition where data is written beyond the boundaries of the allocated receive buffer.
The operational impact of this flaw centers on memory corruption within the BEAM virtual machine's allocator subsystem. When the oversized write occurs, it overwrites the allocator metadata footer associated with the current block and potentially corrupts adjacent blocks in the heap structure. This destruction of internal memory management structures typically leads to an immediate crash or termination of the Erlang node process due to detected inconsistencies during subsequent allocation or garbage collection cycles. While the primary outcome is a denial of service through system instability, the theoretical possibility of remote code execution exists if an attacker can precisely control the overflowed data and heap layout. However, achieving reliable exploitation for arbitrary code execution is considered extremely unfeasible given the complexity of bypassing modern memory protection mechanisms such as ASLR and DEP within this specific context, making denial of service the most likely practical consequence.
This vulnerability maps directly to CWE-190 Integer Overflow or Wraparound, which describes situations where an arithmetic operation results in a value that exceeds the maximum limit for its data type, leading to unexpected behavior. Furthermore, it aligns with CWE-787 Out-of-bounds Write, as the overflow allows writing memory outside of allocated boundaries. From a tactical perspective, this represents a classic network-based attack vector categorized under MITRE ATT&CK technique T1496 Resource Hijacking or potentially T1059 Command and Scripting Interpreter if exploitation were feasible, though currently it is primarily observed in contexts leading to service disruption rather than persistent access. The vulnerability affects Erlang/OTP versions ranging from OTP 17.0 up to specific patch levels in the 27.x, 28.x, and 29.x branches, corresponding to ERTS releases from version 6.0 through 17.0 depending on the specific branch.
Mitigation strategies must prioritize immediate software updates for all affected systems. Organizations running Erlang/OTP should upgrade to OTP 27.3.4.17 or later, OTP 28.5.0.6 or later, and OTP 29.0.6 or later to resolve the underlying integer overflow logic in the inet driver. For environments where immediate patching is not possible, network-level controls should be implemented to restrict access to Erlang TCP ports exclusively from trusted IP addresses using firewall rules. Additionally, deploying intrusion detection systems capable of identifying anomalous packet sizes or malformed binary protocols can help mitigate exploitation attempts by blocking suspicious traffic before it reaches the vulnerable application layer. Regular auditing of open ports and enforcing strict input validation on all network-facing services remain essential defensive practices to prevent similar memory corruption vulnerabilities in distributed computing environments.