Quarkus REST has potential worker thread starvation when HTTP connection is closed while waiting to write
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 3.31.0, 3.27.2, 3.20.5
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
Quarkus is a Cloud Native, (Linux) Container First framework for writing Java applications. Prior to versions 3.31.0, 3.27.2, and 3.20.5, a vulnerability exists in the HTTP layer of Quarkus REST related to response handling. When a response is being written, 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. This issue has been patched in versions 3.31.0, 3.27.2, and 3.20.5. A workaround involves implementing a health check that monitors the status and saturation of the worker thread pool to detect abnormal thread retention early.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- quarkusio quarkus
From 3.30.0 · fixed in 3.31.0; From 3.21.0 · fixed in 3.27.2; fixed in 3.20.5
- io.quarkus:quarkus-restMaven
fixed in 3.20.5
- io.quarkus:quarkus-restMaven
From 3.21.0 · fixed in 3.27.2
- io.quarkus:quarkus-restMaven
From 3.30.0 · fixed in 3.31.0