Description

A flaw was found in the SmallRye Fault Tolerance library, which is used by Quarkus to provide strategies like retries and circuit breakers for microservices. The issue occurs when using the ApplyGuard or ApplyFaultTolerance annotations, where the library fails to release internal tracking objects after each request. This causes a steady increase in memory usage that eventually leads to the application slowing down and crashing due to lack of memory.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-21T17:19:20.097Z",
  "pubdate": "2026-09-21T17:19:20.097Z",
  "executiveSummary": "A memory leak vulnerability has been identified in the SmallRye Fault Tolerance library, integrated within the Quarkus framework.\nThe flaw originates from the improper lifecycle management of internal tracking objects associated with fault tolerance annotations.\nAn attacker can trigger this vulnerability by repeatedly submitting requests to endpoints instrumented with 'ApplyGuard' or 'ApplyFaultTolerance' decorators.\nThe sustained accumulation of these objects leads to progressive heap exhaustion, resulting in degraded performance and subsequent application unavailability due to an OutOfMemoryError (OOM).\nThis vulnerability is categorized as a resource management issue, specifically a memory leak, which poses a significant risk to service availability and system stability.\nExploitation does not require elevated privileges; any remote user capable of interacting with the affected microservice endpoints can induce the leak by generating standard application traffic.",
  "technicalDetails": "The vulnerability resides within the internal state management mechanisms of the SmallRye Fault Tolerance library. Specifically, when the library processes requests intercepted by 'ApplyGuard' or 'ApplyFaultTolerance' annotations, it initializes and maintains internal tracking structures necessary to monitor retries, circuit breaker states, and execution metrics.\nThe root cause of this vulnerability is a failure in the object lifecycle management logic, where these internal tracking objects are not correctly deregistered or garbage collected upon the completion of a request. Because these objects remain strongly referenced within the library's internal state containers, the Java Virtual Machine (JVM) garbage collector is unable to reclaim the allocated memory, even after the respective request-response cycle has concluded.\nThe attack flow follows a predictable pattern: an unauthenticated remote user sends a sequence of requests to the affected microservice. For each request processed by an annotated method, the SmallRye library allocates new tracking objects. Due to the failure to release these objects, the heap memory usage grows monotonically with every incoming request. Eventually, the JVM reaches its maximum heap capacity, causing the application to enter a state of severe performance degradation as garbage collection cycles become increasingly frequent and ineffective, eventually terminating the application via an OutOfMemoryError.\nThe vulnerability is inherent to the component responsible for managing fault tolerance metadata and runtime execution context. Because the leakage is tied directly to the execution of the fault tolerance interceptors, the impact is proportional to the request volume; high-traffic environments are susceptible to a faster time-to-crash. No specific payload is required beyond standard valid traffic to the affected endpoints, as the vulnerability is triggered by the routine use of the library's features rather than a malformed input vector.\nThe lack of object release prevents the reclamation of memory associated with stale execution contexts, turning the library into a source of memory pressure that is not bounded by the standard request lifecycle. Post-exploitation impact is limited to denial-of-service (DoS) via resource exhaustion, as there is no evidence of arbitrary code execution or data exfiltration associated with this memory leak."
}