CVE-2025-1634: Quarkus RESTEasy DoS Vulnerability

CVE-2025-1634 Overview

A memory leak vulnerability has been identified in the Quarkus RESTEasy extension that can lead to denial of service conditions. The flaw occurs when client requests with low timeouts are processed by the application. When a client request times out, a buffer is not released correctly, causing increased memory usage over time. Continued exploitation of this vulnerability can eventually crash the application due to an OutOfMemoryError, impacting service availability.

Critical Impact

Applications using the quarkus-resteasy extension are vulnerable to resource exhaustion attacks. Attackers can send numerous requests with low timeouts to trigger memory leaks, eventually causing application crashes and denial of service.

Affected Products

• Quarkus RESTEasy Extension (unpatched versions)
• Red Hat build of Quarkus (see Red Hat Security Advisories for specific versions)
• Applications built on affected Quarkus frameworks

Discovery Timeline

• 2025-02-26 - CVE-2025-1634 published to NVD
• 2025-12-17 - Last updated in NVD database

Technical Details for CVE-2025-1634

Vulnerability Analysis

This vulnerability is classified under CWE-401 (Missing Release of Memory after Effective Lifetime), a common weakness pattern where allocated memory is not properly freed after its intended use. In the context of the quarkus-resteasy extension, the issue manifests during request timeout handling. When a client connection times out before the server completes processing, the internal buffer allocated for that request remains unreleased.

The network-accessible nature of this vulnerability means attackers can trigger it remotely without authentication. The attack complexity is low, requiring no special privileges or user interaction. While the vulnerability does not compromise data confidentiality or integrity, it poses a significant availability risk as accumulated memory leaks will eventually exhaust available heap space.

Root Cause

The root cause lies in improper resource management within the quarkus-resteasy extension's timeout handling code path. When a client request experiences a timeout condition, the normal cleanup routine that would release associated memory buffers is bypassed or fails to execute completely. This results in orphaned buffer objects that cannot be garbage collected, as they remain referenced within the application's memory space.

Attack Vector

An attacker can exploit this vulnerability by sending a high volume of HTTP requests to a Quarkus application using the RESTEasy extension, configured with artificially low client-side timeouts. The attack pattern involves:

1. Establishing connections to the target application
2. Sending requests that initiate server-side processing
3. Disconnecting or timing out before the response is delivered
4. Repeating this process to accumulate memory leaks
5. Continuing until the application exhausts available memory and crashes

The vulnerability is particularly concerning because it can be exploited without authentication, making any publicly accessible Quarkus RESTEasy endpoint a potential target for denial of service attacks.

Detection Methods for CVE-2025-1634

Indicators of Compromise

• Gradual increase in JVM heap memory usage without corresponding workload increase
• Frequent garbage collection events with minimal memory reclamation
• Application logs showing OutOfMemoryError exceptions
• Unusual patterns of short-lived client connections with timeouts
• Memory profiler showing accumulation of buffer objects

Detection Strategies

• Monitor JVM heap memory metrics for sustained growth patterns indicating memory leaks
• Implement alerting on garbage collection frequency and efficiency degradation
• Analyze access logs for patterns of rapid connection attempts followed by timeouts
• Use application performance monitoring (APM) tools to track memory allocation trends
• Deploy SentinelOne Singularity to detect anomalous resource consumption patterns

Monitoring Recommendations

• Configure JVM memory monitoring with thresholds for heap utilization alerts
• Implement log aggregation to correlate timeout events with memory growth
• Set up application health checks that include memory utilization metrics
• Use container orchestration platform metrics to detect resource exhaustion trends

How to Mitigate CVE-2025-1634

Immediate Actions Required

• Identify all applications using the quarkus-resteasy extension in your environment
• Apply patches from Red Hat Security Advisories (RHSA-2025:1884, RHSA-2025:1885, RHSA-2025:2067)
• Increase monitoring of affected applications until patches are deployed
• Consider implementing rate limiting to reduce exposure to exploitation attempts

Patch Information

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

• RHSA-2025:1884 - Red Hat build of Quarkus security update
• RHSA-2025:1885 - Red Hat build of Quarkus security update
• RHSA-2025:2067 - Red Hat build of Quarkus security update
• RHSA-2025:9922 - Red Hat build of Quarkus security update
• RHSA-2025:12511 - Red Hat build of Quarkus security update
• RHSA-2025:23417 - Red Hat build of Quarkus security update

Additional details are available in Red Hat Bug Report #2347319 and the Red Hat CVE-2025-1634 Details page.

Workarounds

• Implement request rate limiting at the load balancer or API gateway level to reduce attack surface
• Configure automatic application restart policies when memory thresholds are exceeded
• Deploy behind a web application firewall (WAF) with connection timeout policies
• Increase JVM heap allocation as a temporary measure to extend time before exhaustion

# Example JVM configuration to increase heap and enable memory monitoring
# Add to application startup configuration
JAVA_OPTS="-Xmx4g -Xms2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdumps"

# Example rate limiting with nginx (place in upstream or server block)
# limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
# limit_req zone=api_limit burst=200 nodelay;