CVE-2026-87742

Overview

Quarkus is a Kubernetes-native Java framework optimized for cloud-native applications, containers, and serverless workloads. It builds on standard libraries (Jakarta EE, Eclipse Vert.x, Hibernate, Netty) and compiles to both JVM and GraalVM native images for fast startup and low memory use. The WebSockets Next extension (io.quarkus:quarkus-websockets-next) provides annotation-driven WebSocket server endpoints and clients built on Vert.x.

A denial of service vulnerability (CVE-2026-87742) has been identified in the Quarkus WebSockets Next extension, which allows attackers to exhaust heap memory and crash the JVM by streaming WebSocket messages over a single connection faster than the application can process them. When the endpoint does not require authentication, an unauthenticated remote attacker can trigger the crash.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects multiple versions of Quarkus that include the io.quarkus:quarkus-websockets-next package.

Details

Module Info

• Product: Quarkus
• Affected packages: io.quarkus:quarkus-websockets-next
• Affected versions: >=3.9.0 <3.27.5.3, >=3.28.0 <3.33.3.3, >=3.34.0<3.39.5
• GitHub repository: https://github.com/quarkusio/quarkus
• Published packages: https://central.sonatype.com/artifact/io.quarkus/quarkus-websockets-next
• Package manager: Maven
• Fixed in:
  • OSS Quarkus 3.27.5.3, 3.33.3.3, 3.39.5
  • NES for Quarkus v3.20.10

Vulnerability Info

This High-severity vulnerability is found in the io.quarkus:quarkus-websockets-next package in multiple versions of Quarkus, having been first introduced in 3.9.0. The extension registers Vert.x message handlers on each WebSocket connection but never applies read backpressure to the underlying socket. Every inbound text or binary message is dispatched for processing as soon as it arrives, whether or not the handler has finished with the previous one:

ws.textMessageHandler(new Handler<String>() {
    @Override
    public void handle(String message) {
        Context duplicatedContext = newDuplicatedContext
                ? ContextSupport.createNewDuplicatedContext(context, connection)
                : context;
        duplicatedContext.runOnContext(new Handler<Void>() {
            @Override
            public void handle(Void event) {
                textAction.accept(message);
            }
        });
    }
});

The read stream is never paused, and the completion of an @OnTextMessage or @OnBinaryMessage callback does not control how many further messages are read. To serialize callback invocations, the per-connection ConcurrencyLimiter places every message that arrives while a callback is still running into an unbounded multi-producer queue:

this.queue = Queues.createMpscQueue();
...
queue.offer(new Action(queueIndex, action, context));

Nothing limits the number of queued messages per connection. A peer that sends messages (each just under the default 256 KB size limit) faster than the endpoint handler drains them causes the queued messages and their payloads to accumulate on the heap until the JVM fails with java.lang.OutOfMemoryError, taking down the whole application.

Mitigation

Only recent versions of Quarkus are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue. Quarkus LTS releases are maintained for 12 months from release; see the project's LTS release policy.

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

• Mike Read from JPMorganChase (finder)