CVE-2025-66560: Quarkus REST DoS Vulnerability

CVE-2025-66560 Overview

CVE-2025-66560 is a resource exhaustion vulnerability affecting the HTTP layer of Quarkus REST, a Cloud Native, (Linux) Container First framework for writing Java applications. The vulnerability stems from improper handling of response transmission when client connections are dropped during the waiting period for previously written response chunks to be fully transmitted.

When a response is being written in Quarkus REST, the framework waits for previously written response chunks to be fully transmitted before proceeding. If the client connection is dropped during this waiting period, the associated worker thread is never released and becomes permanently blocked. Under sustained or repeated occurrences, this can exhaust the available worker threads, leading to degraded performance or complete unavailability of the application.

Critical Impact

This vulnerability allows remote attackers to cause denial of service by exhausting worker threads through repeated connection drops during HTTP response transmission, potentially rendering applications completely unavailable.

Affected Products

• Quarkus versions prior to 3.31.0
• Quarkus versions prior to 3.27.2
• Quarkus versions prior to 3.20.5

Discovery Timeline

• 2026-01-07 - CVE CVE-2025-66560 published to NVD
• 2026-01-08 - Last updated in NVD database

Technical Details for CVE-2025-66560

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The flaw exists in Quarkus REST's HTTP response handling mechanism, where worker threads responsible for transmitting HTTP responses can become permanently blocked when client connections are unexpectedly terminated.

The attack exploits a network-based vector where an attacker does not require any privileges or user interaction. The core issue lies in the framework's synchronous waiting mechanism for response chunk acknowledgment. When the HTTP layer waits for confirmation that response data has been transmitted successfully, it does not properly handle the scenario where the receiving client abruptly closes the connection.

Each blocked thread represents a consumed resource from the finite worker thread pool. As these threads accumulate in a blocked state, the application's capacity to handle legitimate requests diminishes proportionally. Eventually, when all worker threads become exhausted, the application can no longer process any incoming requests, resulting in complete service unavailability.

Root Cause

The root cause is improper resource management in the Quarkus REST HTTP response handling layer. Specifically, the framework lacks proper timeout mechanisms or connection state validation during the response transmission wait cycle. When a client disconnects mid-transmission, the worker thread continues waiting indefinitely for an acknowledgment that will never arrive, causing permanent thread blocking.

This represents an allocation of resources without limits vulnerability, as there is no mechanism to detect and recover from stalled worker threads or to limit the impact of accumulated blocked threads on overall system availability.

Attack Vector

The attack can be executed remotely over the network without any authentication or special privileges. An attacker can exploit this vulnerability by:

1. Initiating multiple HTTP requests to a vulnerable Quarkus REST endpoint
2. Timing the connection drop to occur while the server is transmitting response chunks
3. Repeating this process to systematically block worker threads
4. Eventually exhausting the entire worker thread pool, causing denial of service

The attack requires some precision in timing (high attack complexity) but can be automated to increase effectiveness. The vulnerability affects availability only, with no impact on confidentiality or integrity of the system.

Detection Methods for CVE-2025-66560

Indicators of Compromise

• Increasing number of blocked or hung worker threads in JVM thread dumps
• Gradual degradation of application response times under normal load
• Thread pool saturation alerts from monitoring systems
• Connection timeout errors reported by legitimate clients
• Unusual patterns of abruptly closed client connections in access logs

Detection Strategies

• Monitor worker thread pool utilization and set alerts for abnormal saturation levels
• Implement thread dump analysis to detect threads blocked in HTTP response transmission states
• Track and alert on unusual patterns of client connection drops during response phases
• Enable detailed HTTP access logging to identify potential malicious connection patterns
• Configure JMX monitoring for Quarkus thread pool metrics

Monitoring Recommendations

• Deploy application performance monitoring (APM) solutions with thread pool visibility
• Establish baseline metrics for normal worker thread utilization patterns
• Configure automated health checks that specifically monitor worker thread availability
• Set up alerting thresholds for thread pool saturation approaching critical levels
• Implement log aggregation to correlate connection drop patterns across instances

How to Mitigate CVE-2025-66560

Immediate Actions Required

• Upgrade Quarkus to patched versions 3.31.0, 3.27.2, or 3.20.5 depending on your version branch
• Implement health checks to monitor worker thread pool status as an interim measure
• Review and potentially reduce application timeout configurations to limit blocked thread duration
• Consider implementing connection rate limiting at the load balancer or reverse proxy level
• Monitor systems for signs of exploitation during the upgrade process

Patch Information

Quarkus has released security patches in versions 3.31.0, 3.27.2, and 3.20.5. Users should upgrade to the appropriate patched version based on their current Quarkus version branch. For detailed information about the security fix, refer to the GitHub Security Advisory.

Workarounds

• Implement a custom health check that monitors the status and saturation of the worker thread pool to detect abnormal thread retention early
• Configure reverse proxies or load balancers to implement connection timeouts and rate limiting
• Deploy multiple application instances behind a load balancer to distribute risk and maintain availability
• Set up automated instance restarts when thread pool saturation exceeds critical thresholds
• Consider implementing network-level protections to limit connection frequency from individual sources

# Example Quarkus health check configuration for thread pool monitoring
# Add to application.properties
quarkus.smallrye-health.enabled=true
quarkus.smallrye-health.liveness-path=/q/health/live
quarkus.smallrye-health.readiness-path=/q/health/ready

# Configure thread pool monitoring thresholds
quarkus.thread-pool.max-threads=50
quarkus.thread-pool.queue-size=100