A WebSocket flaw in Undertow, the engine inside Red Hat JBoss, lets anyone crash the server with no login

Red Hat published CVE-2026-15565 on August 11, and it carries a line that grabs attention fast: a remote attacker with no account can knock the server over. The flaw sits in Undertow, the web server that Red Hat's Java middleware runs on, and the reach includes JBoss Enterprise Application Platform 7 and 8 plus Data Grid 8. One precondition decides whether it touches you, and there is no patched build yet, so this week's response is mitigation, not an upgrade.

The rating is CVSS 7.5, availability only. An attacker cannot read your data or change it with this bug. What they can do is exhaust the Java heap until the process throws an OutOfMemoryError and stops serving, all through the ordinary WebSocket handshake, which never asks for a credential.

The precondition decides your exposure, not the words "pre-auth"

"Pre-authentication" reads like every JBoss instance on the internet is a target. It is narrower than that. The bug only reaches an application that registers a server-side WebSocket endpoint: a class carrying the @ServerEndpoint annotation with at least one @OnMessage handler. Applications that do not use WebSockets never touch the vulnerable path.

So the real question is not "do I run JBoss," it is "does any app I deploy expose a WebSocket endpoint an unauthenticated client can reach." Live dashboards, chat and notification features, and collaborative tools are the usual places one shows up. Where it does, the pre-auth part is real: the attacker opens the socket before any login, so an internet-facing endpoint has nothing standing in front of the flaw. This joins a run of unauthenticated flaws in enterprise middleware this year, including a pre-auth memory-corruption bug in SAP NetWeaver.

Which Red Hat products are affected

Red Hat lists JBoss EAP 7, JBoss EAP 8, Data Grid 8, and its Camel for Spring Boot 4 build as affected. The JBoss EAP Expansion Pack is marked not affected. Fuse 7 and Single Sign-On 7 were still under investigation when the advisory went out, so treat them as unresolved rather than clear. We covered a separate issue in the same Camel line recently, a header-injection flaw that turned Camel's Solr routes into a request-forgery vector; this one is unrelated, but the same middleware stack keeps producing pre-auth exposure.

How a single message runs the server out of memory

According to Red Hat's bug report, two defects stack. When Undertow receives a text WebSocket message, it spins up an internal buffer named BufferedTextMessage to gather the arriving bytes, and that buffer is created with its size limit set to -1, the value that means unbounded. Even if a ceiling were set, the listener that handles each fragment of an asynchronously delivered message never calls the check that would compare the running total against the ceiling. An attacker connects, then sends a large or fragmented text message that the server keeps buffering with no ceiling, and the heap climbs until it fails.

That detail shapes the defense. This is not a volumetric flood you would catch with a connection-rate limit; one connection sending one oversized message is enough. The control that fits the bug is a cap on WebSocket message size, not on connection count.

No exploit in the wild yet, and no finished fix

As of publication the CVE is not in CISA's Known Exploited Vulnerabilities catalog, and there is no public proof-of-concept circulating that we could confirm. There is also no fixed version yet: Red Hat's bug sits in NEW status with an empty "fixed in" field, and Red Hat notes that an initial upstream pull request "is still not enough to prevent" the denial of service because of the second defect. A live 7.5 with no errata is why the near-term answer is a config change rather than patch-and-move-on. It also echoes a pattern we flagged in a Citrix NetScaler memory-leak flaw: an availability bug where the first fix does not finish the job.

What to do before a patched build ships

Red Hat gives two mitigations, and both turn WebSockets off, so use them only where your apps do not depend on the feature.

• Disable WebSockets for the whole server by removing the `` element from the servlet container config.

• Disable WebSockets per application by setting false in that app's jboss-web.xml.

If an app genuinely needs WebSockets, you cannot simply switch them off, and there is no build to install. In that case put a size cap on WebSocket text messages at the proxy or gateway in front of the instance, and apply Red Hat's errata the moment it lands. Track the CVE page for the fixed version rather than assuming the first upstream patch closed it, since Red Hat has said it does not.

How you would know you were hit

Because the impact is memory, the signal is memory. Watch the JVM heap and garbage-collection metrics on any instance that serves WebSocket endpoints, and alert on OutOfMemoryError events and unexpected process restarts. Tie those to WebSocket activity: a connection that opens and then pushes an unusually large text frame right before the heap spikes is the shape of this attack. A managed detection service that already ingests application and JVM logs can flag the out-of-memory-plus-WebSocket pattern, but even a plain heap-usage alert on your app servers gives early warning that a buffer is filling without a stop.

The uncomfortable part of CVE-2026-15565 is not its severity, it is the timing. A working fix is not ready, and the vendor has said the obvious first patch does not fully close the hole. Until the errata ship, the operators who come out ahead are the ones who can answer one inventory question today, which of my deployed apps expose a WebSocket endpoint, and act on the few that do.