CVE-2026-94449: Quarkus-smallrye-fault-tolerance: quarkus-smallrye-fault-tolerance: memory leak in @applyguard leads to denial of service

Published Sep 21, 2026
·
Updated

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.

Other sources

A memory leak vulnerability was discovered in SmallRye Fault Tolerance core. When a programmatic Guard, TypedGuard, or FaultTolerance is invoked through the ApplyGuard or the deprecated ApplyFaultTolerance annotations, the library retains one DelegatingMeteredOperation and one MetricsCollector instance per invocation for the lifetime of the singleton guard.

The root cause is that these objects are never released, causing the heap to grow linearly with the number of calls. An unauthenticated remote attacker can exploit this by sending a high volume of requests to a vulnerable endpoint, leading to increased garbage collection pressure, significant performance degradation, and an eventual OutOfMemoryError OOM condition. This impact occurs regardless of whether a description is set for the guard.

Red Hat

Affected Software

1 affected component
Quarkus SmallRye Fault Tolerance

Event History

Sep 21, 2026
Data Sourced
via Red Hat·04:45 PM
DescriptionSeverityAffected Software
CVE Published
via MITRE·05:01 PM
Data Sourced
via MITRE·05:01 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:19 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which applications are exposed to this denial-of-service condition?

Applications are exposed when they invoke a programmatic Guard, TypedGuard, or FaultTolerance through the ApplyGuard or deprecated ApplyFaultTolerance annotations. The retained objects persist for the lifetime of the singleton guard, so memory growth is proportional to the number of invocations.

2

What does an attacker need to exploit the issue?

An attacker needs network access to a vulnerable endpoint and can exploit the issue without authentication or user interaction. Sending a high volume of requests causes the affected invocation path to retain objects until memory pressure leads to degraded performance or an OutOfMemoryError.

3

Is this limited to the deprecated ApplyFaultTolerance annotation?

No. The issue affects use through both ApplyGuard and the deprecated ApplyFaultTolerance annotations.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203