CVE-2026-83745: Apache Thrift, Apache Thrift: WebSocket frame decoders allocate the payload buffer from the declared length, not the bytes received (Node.js, D)
Memory allocation with excessive size value, Improper handling of length parameter inconsistency vulnerability in Apache Thrift nodejs and D lang bindings.
Both bindings' WebSocket server transports read the payload length out of the frame header and allocate that many bytes immediately, without checking that the bytes have arrived. A single ~14-byte frame therefore commits as much memory as it cares to declare -- measured at 513 MiB against the Node.js server and 2 GiB against the D transport -- and in the Node.js case the connection is left open afterwards, so the frame can simply be sent again.
This issue affects Apache Thrift before 0.25.0.
Users are recommended to upgrade to version 0.25.0, which fixes the issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Thriftto a version that resolves this vulnerability.Fixed in 0.25.0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Apache Thrift deployments using the Node.js or D language bindings with their WebSocket server transports are affected if they run a version before 0.25.0. Other bindings are not identified in the provided information.
What does an attacker need to do to trigger the memory allocation?
An attacker needs to send a WebSocket frame with a declared payload length larger than the bytes actually received. A frame of roughly 14 bytes can cause the server to allocate memory based on the declared length.
How severe can the memory consumption be, and can it be repeated?
The issue was measured at 513 MiB of allocation against the Node.js server and 2 GiB against the D transport. In Node.js, the connection remains open after the frame, allowing the attacker to send the frame again.
What is the available remediation?
Upgrade Apache Thrift to version 0.25.0, which fixes the issue.