CVE-2026-45112

If you're running Apache Thrift's Java bindings in production, you're likely exposed. Versions 0.19.0 through 0.24.0 ship without default resource limits on message processing—which means malformed or oversized messages from remote clients can trigger unbounded memory allocation. The CVSS 7.5 reflects a genuine network-exploitable condition: Thrift typically handles client-server communication, and an unauthenticated attacker can simply send a oversized payload and exhaust your JVM heap. This isn't a subtle edge case. When the Java heap fills, it doesn't just fail the Thrift handler—it triggers JVM-wide out-of-memory conditions. Your entire service becomes unresponsive, not just the Thrift endpoint. In containerized environments, that OOM can evict adjacent containers from the same node, creating failure cascades that extend well beyond the Thrift layer. The fix in version 0.24.0 introduces resource limits, but here's the operational wrinkle: it may break existing applications that were legitimately sending large messages—batch payloads, file transfers, ML inference inputs. Before upgrading to 0.24.0 in production, test against your actual traffic patterns, not just unit tests. Applications that worked because Thrift silently accepted unbounded input will now fail with limit violations. What to check now: identify every service using Thrift Java bindings, audit the version, and verify whether any legitimate code paths depend on sending large messages. If you're on 0.19.0–0.24.0, plan your upgrade path and test the 0.24.0 upgrade in staging first. Monitor for silent failures after the patch—applications that worked around the unbounded behavior by sending big payloads will surface as errors once limits enforce.

Reviewed through automated stages and approved by a human before publication.