CVE-2026-65653 in tchannel-go
Summary
by MITRE • 09/21/2026
github.com/temporalio/tchannel-go did not reject TChannel call fragments containing checksum metadata but no length-prefixed argument chunks. The fragment reader left its chunk slice empty and then unconditionally selected the first element. A network peer can supply such a malformed call fragment, including as a direct initial call request after completing the standard initialization handshake. On that inbound path, the resulting unrecovered Go slice-bounds panic occurs on a library-created dispatch goroutine and terminates the hosting process. This allows remote denial of service against applications that expose the listener to untrusted peers. The impact is limited to availability; no confidentiality or integrity impact was identified.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability in github.com/temporalio/tchannel-go stems from an improper input validation mechanism within the TChannel protocol implementation, specifically concerning the handling of call fragments that contain checksum metadata but lack length-prefixed argument chunks. In a standard TChannel communication flow, peers exchange messages structured with specific headers and payloads, where integrity is often verified via checksums before processing payload data. However, this library failed to reject malformed frames where the structural expectation for argument chunk lengths was not met despite the presence of other valid metadata fields like checksums. This oversight allows a network peer to craft a specially designed packet that passes initial parsing checks but triggers an internal logic error during subsequent processing stages.
Technically, the flaw resides in the fragment reader component which is responsible for assembling and interpreting incoming data streams. When presented with the aforementioned malformed call fragment, the reader initializes its chunk slice as empty due to the absence of length-prefixed argument chunks. Subsequently, the code unconditionally attempts to access the first element of this empty slice without performing a bounds check or verifying that the slice contains any elements prior to access. This sequence of operations directly results in an unrecovered Go panic related to slice index out of range errors. Because TChannel operates using goroutines for handling inbound connections and dispatching calls, this panic occurs on a library-created dispatch goroutine rather than being caught by application-level error handlers.
The operational impact of this vulnerability is strictly limited to availability, constituting a remote denial-of-service attack vector against applications that expose the TChannel listener to untrusted peers. When the panic triggers, it terminates the hosting process entirely, causing immediate service disruption for all active connections and pending requests handled by that instance. There are no identified impacts on confidentiality or integrity; an attacker cannot exploit this flaw to read sensitive data from memory or modify existing state beyond terminating the application. The attack can be executed as a direct initial call request after completing the standard initialization handshake, meaning it does not require prior authenticated sessions or complex multi-stage interactions, making it highly exploitable by any network-accessible adversary.
From a classification perspective, this vulnerability aligns with CWE-20: Improper Input Validation and CWE-787: Out-of-bounds Read, as the core issue is the failure to validate input structure before accessing memory indices. In terms of attack patterns, it corresponds to MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically under methods involving resource exhaustion or application crashes via malformed inputs. To mitigate this risk, developers should upgrade to a patched version of tchannel-go that includes proper bounds checking before slice access and validates the presence of required payload components such as length-prefixed chunks prior to processing checksums. Additionally, implementing panic recovery mechanisms at higher levels in the goroutine lifecycle can provide a temporary defense-in-depth measure by preventing single-point failures from crashing the entire process until a permanent code fix is deployed.