CVE-2026-94449 in Apache Camel 4 for Quarkus 3
Summary
by MITRE • 09/21/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The SmallRye Fault Tolerance library serves as a critical component for implementing resilience patterns such as retries, circuit breakers, and bulkheads within Quarkus-based microservices architectures. These mechanisms are essential for maintaining system stability in distributed environments where network latency or service failures are common. However, a significant resource management flaw has been identified within the implementation of the ApplyGuard and ApplyFaultTolerance annotations. This vulnerability stems from an improper handling of internal tracking objects that monitor execution context and state during method invocations. Specifically, after each request is processed, these internal objects fail to be released or garbage collected by the Java Virtual Machine due to lingering references maintained by the library's runtime logic.
This failure to release resources results in a classic memory leak scenario where heap usage increases steadily over time as long-lived requests accumulate state information that should have been transient. In high-throughput microservice environments, this accumulation occurs rapidly and continuously. As the application consumes more memory to store these unreleased tracking objects, it eventually approaches its configured maximum heap size limits. Once this threshold is reached, the Java Virtual Machine begins frequent garbage collection cycles in an attempt to reclaim space, leading to severe performance degradation characterized by increased latency and reduced throughput.
The operational impact of this vulnerability escalates until the application exhausts all available memory resources. At this stage, the service becomes unresponsive or crashes entirely with OutOfMemoryError exceptions, causing a denial of service for downstream consumers relying on that specific microservice. This behavior undermines the very resilience patterns SmallRye Fault Tolerance is designed to provide, as the system fails under load rather than gracefully degrading or recovering. The issue affects any application utilizing these annotations without proper lifecycle management configurations, posing a risk to production stability particularly in long-running processes where memory leaks compound over days or weeks of operation.
From a classification perspective, this flaw aligns with CWE-401 which describes the improper release of resources before termination, often referred to as a missing free call or resource leak. It also relates to CWE-772 regarding Missing Release of Resource after Effective Lifetime because the tracking objects retain their references beyond the scope of the request lifecycle. In terms of adversarial tactics, while this is not directly exploitable for remote code execution, it facilitates Denial of Service attacks as described in MITRE ATT&CK technique T1499 which covers Endpoint Denial of Service through resource exhaustion. Attackers could potentially accelerate this condition by generating sustained traffic patterns that trigger the faulty annotation logic repeatedly.
Mitigation strategies should focus on upgrading to a patched version of SmallRye Fault Tolerance where the internal reference handling has been corrected to ensure proper cleanup after request completion. Application developers must also monitor heap usage metrics closely using tools like Prometheus or JMX if an immediate upgrade is not feasible, allowing for early detection of abnormal memory growth trends. Additionally, configuring appropriate JVM garbage collection parameters and setting strict memory limits can help contain the impact by triggering restarts before total system failure occurs, although this serves only as a temporary workaround rather than a permanent fix. Ensuring that all dependencies are kept up to date with security patches is vital for maintaining the integrity of microservice resilience frameworks.