CVE-2025-66560

Overview

Quarkus is a Kubernetes-native Java framework optimized for cloud-native applications, containers, and serverless workloads. It is designed around fast startup, low memory use, build-time processing, and developer-friendly integrations across REST, HTTP, security, data, messaging, and observability extensions.

A Denial of Service (DoS) vulnerability (CVE-2025-66560) has been identified in Quarkus REST response handling, which allows attackers to permanently tie up worker threads by closing HTTP connections while the framework is waiting for a full write queue to drain. Repeated triggering can exhaust the worker thread pool and make an affected application unavailable.

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 REST.

‍

Details

Module Info

• Product: Quarkus
• Affected packages:
  
  • quarkus-rest
  • quarkus-resteasy-reactive
• Affected versions: <3.20.5, >=3.21.0 <3.27.2, >=3.30.0 <3.31.0
• GitHub repository: https://github.com/quarkusio/quarkus
• Published packages:
  
  • https://central.sonatype.com/artifact/io.quarkus/quarkus-rest
  • https://central.sonatype.com/artifact/io.quarkus/quarkus-resteasy-reactive
• Package manager: Maven
• Fixed in:
  
  • NES for Quarkus 2.16.x
  • OSS Quarkus 3.20.5, 3.27.2 and 3.31.0

Vulnerability Info

This Medium-severity vulnerability is found in the io.quarkus:quarkus-rest package. In the NES-supported 2.16.x line, the same response-writing logic is present in io.quarkus:quarkus-resteasy-reactive. When a blocking endpoint writes a response and the Vert.x response write queue is full, the output stream waits on the HTTP connection monitor until the drain handler wakes it. The vulnerable code checks whether the response is closed before waiting, but then calls wait() without a timeout:

while (request.response().writeQueueFull()) {
    if (throwable != null) {
        throw new IOException(throwable);
    }
    if (request.response().closed()) {
        throw new IOException("Connection has been closed");
    }
    registerDrainHandler();
    try {
        waitingForDrain = true;
        request.connection().wait();
    } catch (InterruptedException e) {
        throw new InterruptedIOException(e.getMessage());
    } finally {
        waitingForDrain = false;
    }
}

If the client connection closes after that pre-check and before a drain notification wakes the monitor, the worker thread can stay blocked indefinitely. A remote attacker who repeatedly creates the full-write-queue timing condition can retain worker threads until the application has too few available workers to service legitimate traffic. The issue affects availability only and requires a timing-sensitive response-write condition, which is why the advisory rates the attack complexity as high.

‍

Mitigation

Only recent versions of Quarkus are community-supported. The affected 2.16.x line is End-of-Life and will not receive public updates to address this issue.

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

• Shaswata Jash from Nokia (finder)