CVE-2026-66055 in Thrift
Summary
by MITRE • 10/02/2026
Allocation of Resources Without Limits or Throttling vulnerability in Apache Thrift C++, Java, Go, netstd, Python and Delphi bindings.
This issue affects Apache Thrift: before 0.25.0.
Users are recommended to upgrade to version 0.25.0, which fixes the issue.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified as an allocation of resources without limits or throttling in Apache Thrift represents a significant risk to system stability and availability across multiple programming language bindings including C++, Java, Go, .NET Standard, Python, and Delphi. This flaw exists in versions prior to 0.25.0 and stems from the framework's handling of resource consumption during request processing or data serialization operations. Apache Thrift is a widely used cross-language RPC framework that enables efficient communication between services written in different languages. When the underlying implementation fails to enforce strict limits on memory allocation, CPU usage, or connection counts, it creates an environment where malicious actors can exploit unbounded resource growth. This type of vulnerability is fundamentally categorized under CWE-770: Allocation of Resources Without Limits or Throttling within the Common Weakness Enumeration standard, which highlights failures in application logic to restrict the amount of resources a user or process may consume.
From a technical perspective, the absence of throttling mechanisms allows an attacker to trigger excessive resource allocation through crafted inputs or sustained high-volume requests. In languages like C++ and Java, this might manifest as heap exhaustion due to unbounded buffer expansions during deserialization of large payloads. For interpreted languages such as Python and Go, it could lead to garbage collection pressure spikes or goroutine leaks that degrade performance over time. The core issue lies in the lack of validation on input sizes, request rates, or concurrent connection limits before allocating memory or establishing threads. Without these safeguards, a single client can monopolize server resources by sending requests that require disproportionate computational effort or memory footprint relative to their actual utility. This behavior aligns with ATT&CK technique T1496: Resource Hijacking, where adversaries leverage compromised systems for cryptomining or other resource-intensive activities, although in this context the hijacking is unintentional and results from poor design rather than active exploitation by an attacker seeking computational power.
The operational impact of this vulnerability is primarily centered on denial-of-service conditions that affect both availability and performance integrity. Systems running vulnerable versions of Apache Thrift are susceptible to sudden crashes or severe latency increases when subjected to moderate traffic levels designed to trigger the unbounded allocation behavior. In production environments, this can lead to cascading failures where one overloaded service causes downstream dependencies to timeout or fail as well. Additionally, because resource exhaustion often occurs silently until critical thresholds are breached, monitoring and alerting systems may not detect the issue in time to prevent service disruption. The lack of rate limiting also means that automated tools or scripts can easily overwhelm a target without requiring sophisticated evasion techniques, making this vulnerability particularly dangerous against public-facing APIs built on Apache Thrift.
Mitigation strategies must prioritize upgrading to version 0.25.0 which addresses the root cause by implementing proper resource constraints and validation checks within the framework's core logic. Organizations should also enforce network-level rate limiting using reverse proxies or load balancers to cap request rates before they reach the application layer. Implementing strict input size limits for all serialized data structures is essential to prevent memory exhaustion attacks. Furthermore, developers should review their Thrift service implementations to ensure that any custom handlers do not introduce additional unbounded allocations. Regular security audits focusing on resource management patterns and adherence to CWE-770 guidelines will help identify similar weaknesses in other components of the system architecture.