CVE-2025-2240: Smallrye Fault Tolerance DoS Vulnerability

CVE-2025-2240 Overview

A memory exhaustion vulnerability has been identified in SmallRye Fault Tolerance, a library providing fault tolerance capabilities for MicroProfile applications. The flaw exists in the metrics endpoint handling, where repeated calls to the metrics URI create new objects within the meterMap data structure without proper cleanup or bounds checking. This unbounded object allocation can be exploited by an attacker to trigger an out-of-memory (OOM) condition, leading to a denial of service (DoS) against affected applications.

Critical Impact

Remote attackers can exhaust application memory by repeatedly calling the metrics endpoint, causing service unavailability without requiring authentication.

Affected Products

• SmallRye Fault Tolerance (smallrye-fault-tolerance)
• Red Hat products utilizing SmallRye Fault Tolerance components
• MicroProfile-based applications implementing smallrye-fault-tolerance

Discovery Timeline

• March 12, 2025 - CVE-2025-2240 published to NVD
• May 21, 2025 - Last updated in NVD database

Technical Details for CVE-2025-2240

Vulnerability Analysis

This vulnerability falls under CWE-1325 (Improperly Controlled Sequential Memory Allocation), indicating a design flaw where memory allocation is not properly bounded during sequential operations. The vulnerability is externally triggered through network-accessible metrics endpoints, requiring no authentication or special privileges to exploit. The impact is limited to availability (denial of service) with no direct effect on data confidentiality or integrity.

The core issue lies in how the SmallRye Fault Tolerance library handles metric registration. When the metrics URI is called, the application creates new meter objects that are stored in an internal meterMap. Under normal operation, this map should maintain a bounded set of meters corresponding to the application's fault tolerance configurations. However, due to the flaw, each call to the metrics endpoint can result in the creation of additional objects that persist in memory.

Root Cause

The root cause is improper memory management in the metrics collection component of smallrye-fault-tolerance. Specifically, the meterMap data structure lacks proper deduplication or size limiting mechanisms, allowing unbounded growth. When metric requests are processed, new meter objects are instantiated and added to the map without checking for existing entries or enforcing a maximum capacity. This violates the principle of controlled resource allocation and creates an exploitable resource exhaustion condition.

Attack Vector

The attack is network-based and requires no authentication, making it relatively straightforward to execute. An attacker can exploit this vulnerability by:

1. Identifying a target application running smallrye-fault-tolerance with exposed metrics endpoints
2. Sending repeated HTTP requests to the metrics URI
3. Each request triggers the creation of new objects in the meterMap
4. Continued requests cause the JVM heap to grow until memory is exhausted
5. The application throws OutOfMemoryError exceptions and becomes unresponsive or crashes

The attack requires sustained request traffic but can be amplified through scripted automation. The vulnerability is particularly dangerous in containerized environments where memory limits may cause immediate pod termination when exceeded.

Detection Methods for CVE-2025-2240

Indicators of Compromise

• Unusual spike in HTTP requests targeting metrics endpoints (e.g., /metrics, /q/metrics)
• Rapidly increasing JVM heap memory consumption without corresponding application activity
• OutOfMemoryError exceptions in application logs with heap exhaustion
• Application restarts or crashes correlated with external traffic patterns
• Abnormally large meterMap or metric registry object sizes in heap dumps

Detection Strategies

• Implement rate limiting on metrics endpoints and alert on threshold breaches
• Monitor JVM heap utilization trends and alert on sustained growth patterns
• Configure application performance monitoring (APM) to track metric registry object counts
• Enable garbage collection logging to identify memory pressure indicators
• Deploy web application firewall (WAF) rules to detect repetitive metrics endpoint access patterns

Monitoring Recommendations

• Set up alerts for JVM memory utilization exceeding 80% capacity with sustained duration
• Monitor metrics endpoint request rates and establish baseline thresholds for anomaly detection
• Implement distributed tracing to correlate memory growth with specific endpoint activity
• Enable container memory limit alerts in orchestration platforms like Kubernetes
• Configure log aggregation to centralize and correlate OOM events across service instances

How to Mitigate CVE-2025-2240

Immediate Actions Required

• Apply the latest security patches from Red Hat advisories (RHSA-2025:3376, RHSA-2025:3541, RHSA-2025:3543)
• Restrict access to metrics endpoints through network segmentation or authentication requirements
• Implement rate limiting on metrics URI paths to prevent rapid repeated requests
• Review and update smallrye-fault-tolerance dependencies to patched versions
• Consider temporarily disabling metrics endpoints if not critical to operations until patching is complete

Patch Information

Red Hat has released multiple security advisories addressing this vulnerability. Organizations should apply the appropriate patches based on their deployed products:

• Red Hat Security Advisory RHSA-2025:3376
• Red Hat Security Advisory RHSA-2025:3541
• Red Hat Security Advisory RHSA-2025:3543

Additional details are available in the Red Hat CVE Report for CVE-2025-2240, Red Hat Bug Report #2351452, and the GitHub Security Advisory GHSA-gfh6-3pqw-x2j4.

Workarounds

• Implement reverse proxy or API gateway rate limiting for metrics endpoints (e.g., limit to 10 requests per minute per IP)
• Restrict metrics endpoint access to internal networks only using firewall rules or network policies
• Add authentication requirements to metrics endpoints if the application framework supports it
• Configure JVM memory limits and implement graceful degradation handling for OOM scenarios
• Deploy monitoring to detect and automatically restart affected services as a temporary resilience measure

# Example nginx rate limiting configuration for metrics endpoints
limit_req_zone $binary_remote_addr zone=metrics_limit:10m rate=10r/m;

location /metrics {
    limit_req zone=metrics_limit burst=5 nodelay;
    # Optionally restrict to internal IPs only
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
    proxy_pass http://backend;
}