CVE-2026-61374 in Thrift
Summary
by MITRE • 10/02/2026
Allocation of Resources Without Limits or Throttling vulnerability in Apache Thrift Java bindings.
This issue affects Apache Thrift: before 0.25.0.
Users are recommended to upgrade to version 0.25.0, which fixes the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The identified vulnerability represents a critical flaw within the Apache Thrift framework, specifically affecting its Java bindings prior to version 0.25.0. This security deficiency is categorized under CWE-770: Allocation of Resources Without Limits or Throttling, which describes scenarios where an application allocates resources without imposing restrictions on the quantity or rate of allocation. In the context of networked services like those built with Apache Thrift, this flaw allows a client to consume excessive server-side resources by initiating a high volume of requests or sending large payloads that trigger disproportionate memory or CPU consumption during serialization and deserialization processes. The absence of inherent throttling mechanisms means that the service remains vulnerable to resource exhaustion attacks even under moderate load conditions if not externally managed.
From an operational perspective, this vulnerability can be exploited to achieve a Denial of Service against the target application server. An attacker can leverage this flaw by sending specially crafted requests that force the Java Virtual Machine to allocate excessive memory for object instantiation or buffer management during RPC calls. This uncontrolled allocation leads to increased garbage collection pressure, potential OutOfMemoryError exceptions, and eventual service instability or crash. The impact is particularly severe in high-throughput environments where Apache Thrift is used as a core component of microservices architectures, as the degradation affects not just individual endpoints but potentially the entire cluster if load balancing distributes malicious traffic across multiple nodes without rate limiting controls at the infrastructure level.
The technical root cause lies in how earlier versions of the Java bindings handled incoming data streams and object graphs. Without strict limits on recursion depth or buffer sizes during protocol parsing, an adversary can craft payloads that expand significantly when deserialized, a technique often associated with XML External Entity attacks but applicable to binary protocols like Thrift as well. This behavior aligns with ATT&CK tactic T1496: Resource Hijacking, where attackers consume computational resources to degrade service availability or potentially mine cryptocurrency in extreme cases of unmitigated resource consumption. The lack of built-in safeguards means that the application relies entirely on external network controls for protection, which may not be configured correctly by default administrators focused on functionality rather than security hardening.
To mitigate this vulnerability, organizations must upgrade Apache Thrift to version 0.25.0 or later, where these allocation limits and throttling mechanisms have been implemented within the framework itself. In addition to upgrading, it is advisable to implement network-level rate limiting using reverse proxies such as Nginx or HAProxy to restrict the number of requests per second from any single client IP address. Furthermore, application-layer monitoring should be enabled to detect anomalous spikes in memory usage or request latency that may indicate an ongoing exploitation attempt. Security teams should also review their deployment configurations to ensure that JVM heap sizes are appropriately tuned and that garbage collection logs are monitored for signs of excessive allocation pressure associated with this specific flaw.