CVE-2026-26445: Stomper Message Broker DOS Vulnerability

CVE-2026-26445 Overview

CVE-2026-26445 is a denial of service vulnerability in the stomper STOMP broker at commit 5e2741e. A malicious client can send partial STOMP frames while keeping TCP connections open. The broker uses edge-triggered epoll (EPOLLET) combined with MSG_PEEK in recv(), which causes affected sockets to enter a permanent half-read state. Once enough of these connections accumulate, the broker stops receiving further epoll events and hangs in epoll_wait. The result is that the broker refuses to process new messages, effectively denying service to legitimate clients.

Critical Impact
Remote unauthenticated attackers can hang the stomper broker by opening a small number of partial STOMP connections, stopping all message processing.

Affected Products

stomper STOMP broker at commit 5e2741e
Deployments using edge-triggered epoll with MSG_PEEK recv semantics
Downstream forks or builds derived from the vulnerable commit

Discovery Timeline

2026-08-26 - CVE-2026-26445 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-26445

Vulnerability Analysis

The stomper broker exposes a Simple Text Oriented Messaging Protocol (STOMP) endpoint over TCP. Client sockets are registered with an epoll instance in edge-triggered mode using the EPOLLET flag. Edge-triggered epoll only reports readiness transitions, so the broker must fully drain each socket on every notification.

The broker uses recv() with the MSG_PEEK flag to inspect incoming STOMP frames without consuming them from the kernel receive buffer. When a client transmits only part of a STOMP frame and pauses, the peeked data remains in the buffer. Because the broker never fully drains the socket, no new EPOLLIN edge event is delivered for that connection.

With enough half-open connections held in this state, all worker attention on those file descriptors ceases. The broker eventually stalls in epoll_wait and stops processing new messages from any client. This is a classic resource-exhaustion denial of service pattern rooted in incorrect edge-triggered epoll handling [CWE-834 style behavior].

Root Cause

The root cause is the interaction between EPOLLET and MSG_PEEK. Edge-triggered epoll requires reads until EAGAIN, but MSG_PEEK never removes bytes from the socket buffer. Partial frames therefore never advance state and never generate the next readiness edge.

Attack Vector

An unauthenticated remote attacker connects to the broker's STOMP TCP port. The attacker sends a truncated STOMP frame such as the first few bytes of a CONNECT command and keeps the TCP session open. Repeating this across multiple sockets exhausts the broker's ability to process events. No authentication, valid credentials, or STOMP handshake completion is required.

See the GitHub Vulnerability Report and the stomper repository for reproduction details.

Detection Methods for CVE-2026-26445

Indicators of Compromise

Multiple long-lived TCP connections to the STOMP listener from a single source without completed frames
Broker process stuck in epoll_wait with growing file descriptor counts and no message throughput
Client reports of timeouts or unacknowledged STOMP SEND and SUBSCRIBE frames

Detection Strategies

Instrument the broker with a per-connection idle and byte-received timer to flag sockets that transmit partial data and stall
Monitor system call activity for repeated recv(..., MSG_PEEK) returning small byte counts on the same file descriptor
Correlate epoll event counts with active connection counts; a large gap indicates stuck sockets

Monitoring Recommendations

Track TCP half-open and slow-write connection metrics on the STOMP port with network flow tools
Alert when the broker's message processing rate drops to zero while connection count remains high
Log source IP addresses that repeatedly open connections and send fewer bytes than a minimal STOMP frame

How to Mitigate CVE-2026-26445

Immediate Actions Required

Restrict network access to the stomper broker port to trusted clients using firewall or security group rules
Place a reverse proxy or load balancer in front of the broker to enforce read timeouts and drop partial frames
Apply per-source connection limits to prevent a single client from monopolizing sockets

Patch Information

No vendor patch is listed in the NVD entry for CVE-2026-26445 at time of publication. Track the stomper repository for a fix. Remediation requires replacing MSG_PEEK-based parsing under EPOLLET with a full-drain read loop that consumes data until EAGAIN and enforces per-connection idle timeouts.

Workarounds

Terminate STOMP connections at a proxy that enforces strict frame timeouts and closes idle or partial sessions
Run the broker behind a rate limiter that caps concurrent connections per source address
Add an operating system level SO_RCVTIMEO or application watchdog to close sockets with unreadable partial data

bash

# Example nftables rule limiting concurrent connections per source to the STOMP port
nft add rule inet filter input tcp dport 61613 ct state new \
  meter stomp_conn { ip saddr limit rate over 10/second } drop