CVE-2026-83663: Apache Thrift: TFramedTransport and THeaderTransport re-enter Read once per frame that carries no payload (Go)
Uncontrolled Recursion vulnerability in Apache Thrift go bindings.
Both Go transports satisfy a read out of a buffered frame and, when that frame yields no payload bytes, read the next frame and call Read again instead of looping. A peer produces such a frame for 4 bytes in TFramedTransport (a declared size of zero) or 18 bytes in THeaderTransport (a header block that fills the frame), so nothing bounds the depth. The Go stack limit is reached as a fatal error, which recover() cannot catch, so the whole process dies.
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 Thrift Go bindingsto a version that resolves this vulnerability.Fixed in 0.25.0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using the Apache Thrift Go bindings before version 0.25.0 are affected when they use TFramedTransport or THeaderTransport and can receive frames from a peer.
What must an attacker send to trigger the process crash?
The peer must repeatedly send payload-free frames: zero-length declared frames for TFramedTransport, or THeaderTransport frames whose header block fills the frame. Each such frame causes another nested Read call until the Go stack limit terminates the process.
Can application-level panic recovery prevent the crash?
No. Reaching the Go stack limit produces a fatal error, and recover() cannot catch it, so the entire process dies.
What is the available remediation?
Upgrade Apache Thrift to version 0.25.0, which fixes the recursive read behavior.