CVE-2026-41602

What it actually does

CVE-2026-41602 is an integer overflow or wraparound flaw in the Apache Thrift Go implementation of TFramedTransport before version 0.23.0. TFramedTransport uses length-prefixed frames to delimit messages; if the Go implementation mishandles a crafted frame size or arithmetic involving that size, an unauthenticated network peer can trigger abnormal allocation, parsing failure, panic, or connection-handling failure. The disclosed impact is availability-only: confidentiality and integrity are not directly affected, but a reachable Thrift service can be crashed or made unavailable.

Why it matters to the business

Services that expose Apache Thrift endpoints using the vulnerable Go TFramedTransport implementation may be disrupted by a remote attacker without authentication or user interaction. The practical consequence is outage risk for internal APIs, microservices, RPC backends, data pipelines, or control-plane components that depend on Thrift. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the flaw is network-reachable, low-complexity, and availability-impacting, so internet-facing or business-critical Thrift services should be upgraded promptly.

How an attack unfolds

An attacker first identifies a network service speaking Apache Thrift over framed transport, commonly by probing known service ports, observing protocol behavior, or targeting applications known to embed Thrift. The attacker then opens a connection and sends a deliberately malformed or oversized frame length designed to trigger integer wraparound in the Go TFramedTransport code path. When the vulnerable service parses the frame, incorrect size arithmetic can cause a runtime panic, excessive memory behavior, or transport failure. Repeating the request across one or more connections can keep the service unstable or unavailable until patched, restarted, rate-limited, or otherwise protected.

How to fix it

Upgrade Apache Thrift to version 0.23.0 or later wherever the Go TFramedTransport implementation is used. Because fixed per-package versions were not provided in the input, review all Go modules, vendored dependencies, container images, and statically linked binaries for Apache Thrift versions before 0.23.0. Rebuild and redeploy affected services after updating dependencies. If immediate upgrade is not possible, reduce exposure by restricting access to Thrift ports, requiring authentication or network-level allowlisting, placing services behind rate limits, limiting maximum frame sizes where configurable, and monitoring/restarting failed workers. These mitigations reduce risk but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm dependency inventories show Apache Thrift version 0.23.0 or later for Go services using TFramedTransport. For Go applications, inspect go.mod, go.sum, SBOMs, vendored module directories, and build pipelines for github.com/apache/thrift or Apache Thrift references older than 0.23.0. Validate that rebuilt binaries or container images include the updated dependency, not only that source files were changed. Perform controlled negative testing in a non-production environment by sending malformed framed-transport inputs and confirming the service rejects them without panic, crash, excessive memory growth, or availability loss. From an exposure perspective, verify that Thrift listener ports are not reachable from untrusted networks unless explicitly required.

Typical attack path

1. Discover a reachable service using Apache Thrift framed transport.
2. Confirm the service accepts unauthenticated or externally reachable Thrift connections.
3. Send a crafted framed-transport message with a malicious length value that triggers integer overflow or wraparound in vulnerable Go code.
4. Cause the server process, worker, or connection handler to panic, exhaust resources, or stop processing requests.
5. Repeat the malformed requests to sustain denial of service against dependent applications or business workflows.

How to detect it

To determine whether exploitation may already have occurred, review application logs, system logs, container runtime logs, orchestrator events, and process supervisor logs for crashes, panics, restarts, out-of-memory events, or sudden connection failures affecting Go services that use Apache Thrift TFramedTransport. Focus on the period since publication and any windows with unexplained service instability. Look for Go panic stack traces referencing Apache Thrift transport code, especially TFramedTransport or framed_transport. Correlate restarts with network telemetry showing repeated short-lived TCP connections, malformed Thrift frames, unusually large frame-length prefixes, or traffic bursts from the same source IPs. Network IDS/packet captures can help identify Thrift framed messages with suspicious length fields near integer boundaries, such as very large 32-bit length values. Because no public exploit or actor-specific indicators are provided, detection should emphasize behavioral evidence of probing and denial-of-service attempts rather than fixed attacker infrastructure.

• TFramedTransport
• framed_transport
• github.com/apache/thrift/lib/go/thrift
• panic: runtime error
• integer overflow
• out of memory
• fatal error: runtime: out of memory
• connection reset by peer
• unexpected EOF
• invalid frame size
• frame size
• Thrift
• CrashLoopBackOff
• OOMKilled

What your security team should do

• Identify all services, containers, and binaries using Apache Thrift Go TFramedTransport before version 0.23.0.
• Prioritize upgrade of internet-facing, partner-facing, and business-critical Thrift services to Apache Thrift 0.23.0 or later.
• Add network controls so only expected clients can reach Thrift service ports.
• Review service crash, panic, and restart telemetry for suspicious spikes since publication on 2026-04-28.
• Add detection for malformed or unusually large framed-transport messages and repeated connection failures to Thrift endpoints.
• Ensure dependency scanning and SBOM generation cover vendored and statically linked Go components.
• If patching is delayed, apply rate limiting, connection limits, frame-size limits where available, and automated recovery while tracking the exception to closure.