CVE-2026-94449

Overview

Quarkus is a Kubernetes-native Java framework optimized for cloud-native applications, containers, and serverless workloads. It builds on standard libraries (Jakarta EE, Eclipse Vert.x, Hibernate, Netty) and compiles to both JVM and GraalVM native images for fast startup and low memory use. The SmallRye Fault Tolerance extension provides retries, circuit breakers, timeouts, bulkheads and other fault tolerance strategies for Quarkus applications, built on the SmallRye Fault Tolerance library.

A denial of service vulnerability (CVE-2026-94449) has been identified in the SmallRye Fault Tolerance extension of Quarkus, which allows attackers to exhaust the application's memory by repeatedly calling a method protected by a programmatic guard through @ApplyGuard or @ApplyFaultTolerance. Each call leaves internal metrics objects behind, so memory use grows until the application slows down and crashes.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects multiple versions of Quarkus that include the io.quarkus:quarkus-smallrye-fault-tolerance package.

Details

Module Info

• Product: Quarkus
• Affected packages: io.quarkus:quarkus-smallrye-fault-tolerance
• Affected versions: >=3.17.0.CR1 <3.27.5.3, >=3.28.0.CR1 <3.33.3.3, >=3.34.0.CR1 <3.39.5, >=3.40.0.CR1 <3.40.0
• GitHub repository: https://github.com/quarkusio/quarkus
• Published packages: https://central.sonatype.com/artifact/io.quarkus/quarkus-smallrye-fault-tolerance
• Package manager: Maven
• Fixed in:
  • OSS Quarkus 3.27.5.3, 3.33.3.3, 3.39.5, 3.40.0
  • NES for Quarkus v3.20.11

Vulnerability Info

This High-severity vulnerability is found in the io.quarkus:quarkus-smallrye-fault-tolerance package in multiple versions of Quarkus. The extension depends on the SmallRye Fault Tolerance library, whose DelegatingMetricsCollector caches one MetricsCollector per metered operation:

private final ConcurrentMap<MeteredOperation, MetricsCollector<V>> cache = new ConcurrentHashMap<>();

@Override
public Future<V> apply(FaultToleranceContext<V> ctx) {
    MeteredOperationName name = ctx.get(MeteredOperationName.class);
    MeteredOperation operation = name != null
            ? new DelegatingMeteredOperation(originalOperation, name.get())
            : originalOperation;
    FaultToleranceStrategy<V> delegate;
    if (operation.enabled()) {
        delegate = cache.computeIfAbsent(operation,
                ignored -> new MetricsCollector<>(this.delegate, provider.create(operation), operation));
    } else {
        delegate = this.delegate;
    }
    return delegate.apply(ctx);
}

When a method annotated with @ApplyGuard (or the deprecated @ApplyFaultTolerance) runs a programmatic Guard, TypedGuard or FaultTolerance, the fault tolerance interceptor puts a new MeteredOperationName into the context on every invocation. apply() therefore wraps the operation in a new DelegatingMeteredOperation each time. That class does not implement equals or hashCode, so the cache, which is keyed by the object instance, never finds an existing entry. Every call adds a new DelegatingMeteredOperation and MetricsCollector to a map that lives as long as the guard, which is usually an application-scoped singleton. An unauthenticated attacker who can repeatedly reach such an endpoint makes the heap grow with each request, causing rising garbage collection pressure, slowdowns and finally an OutOfMemoryError. The exported Micrometer or OpenTelemetry meters stay bounded because they are de-duplicated by name, so the growth does not show up in the metrics themselves. Methods that use only declarative annotations such as @Retry or @CircuitBreaker do not set a MeteredOperationName and are not affected.

Mitigation

Only recent versions of Quarkus are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue. Quarkus LTS releases are maintained for 12 months from release; see the project's LTS release policy.

Users of the affected components should apply one of the following mitigations:

• Upgrade Quarkus to a currently supported release that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Jan from Red Hat (finder)