CVE-2026-55737

Heap pointer corruption via signed/unsigned mismatch in LARGE_TUPLE_EXT decoding in erts external term format decoder

HIGH
7.5
CVSS Score
Published: July 27, 2026 at 03:13 PM UTC
Updated: October 24, 2026 at 01:10 PM UTC
2 products affected across 1 vendorErlang /otpErts

Using OTP by Erlang?

Get instant alerts when new vulnerabilities affect OTP - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.5
Exploit prediction
EPSS 0.3%
SSVC
No known exploit

Description

Signed to Unsigned Conversion Error and Out-of-bounds Write vulnerability in Erlang OTP erts allows an attacker who can supply a crafted Erlang external term format (ETF) binary to binary_to_term/1 to corrupt the BEAM heap pointer and crash the virtual machine. When decoding a LARGE_TUPLE_EXT term, the validation pass decoded_size() in erts/emulator/beam/external.c reads the 32-bit arity field as unsigned (get_uint32()), while the decode pass dec_term() reads the same field as a signed 32-bit integer (get_int32()) into an int. An arity wire value of 0x80000000 passes validation as 2147483648 but decodes as -2147483648, so the subsequent hp += n moves the heap allocation pointer backward. Neither pass enforces the runtime tuple-arity limit MAX_ARITYVAL. The result is an out-of-bounds heap write; in practice the VM detects an impossible heap size and aborts, denying service. The required padding is large when uncompressed but the compressed-ETF envelope shrinks it to a small payload on the wire. This issue affects OTP from OTP 25.0 before 27.3.4.15, 28.5.0.4, and 29.0.4 corresponding to erts from 13.0 before 15.2.7.11, 16.4.0.4, and 17.0.4.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

25.0 ≤ v < 27.3.4.1528.0 ≤ v < 28.5.0.429.0 ≤ v < 29.0.413.025.0ebcbb97b4ec223464cac3d94375739a248ddef6e
Vendor states this is fixed in c5210b42a9d3d96f3d25601942ce8122be0f3761 (fixed)
Affected range stops below 27.3.4.15, so it looks safe — our inference, not a vendor statement
Affected range stops below 28.5.0.4, so it looks safe — our inference, not a vendor statement
Affected range stops below 29.0.4, so it looks safe — our inference, not a vendor statement
13.0 ≤ v < 15.2.7.1116.0 ≤ v < 16.4.0.417.0 ≤ v < 17.0.4
Affected range stops below 15.2.7.11, so it looks safe — our inference, not a vendor statement
Affected range stops below 16.4.0.4, so it looks safe — our inference, not a vendor statement
Affected range stops below 17.0.4, so it looks safe — our inference, not a vendor statement

References (5)

RelatedPatchThird Party Advisory
Source: cverecord
https://cna.erlef.org/cves/CVE-2026-55737.html
RelatedPatchThird Party Advisory
Source: cverecord
https://osv.dev/vulnerability/EEF-CVE-2026-55737
x_version-schemeRelease Notes
Source: cverecord
https://www.erlang.org/doc/system/versions.html#order-of-versions

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
NETWORK
Complexity
LOW
Privileges
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusANALYZED
CWE
CWE-195CWE-787

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card