CVE-2026-26445 in stomper
Summary
by MITRE • 08/26/2026
stomper 5e2741e is vulnerable to Denial of Service. A malicious client can send partial STOMP frames and keep the TCP connections open, which, combined with the broker s use of edge-triggered epoll (EPOLLET) and MSG_PEEK in recv(), causes sockets to enter a permanent half-read state. When enough such connections accumulate, the broker stops receiving any further epoll events for those sockets and eventually hangs in epoll_wait, effectively refusing to process new messages.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Stomper version 5e2741e represents a critical Denial of Service (DoS) flaw rooted in improper handling of partial Transmission Control Protocol (TCP) frames within the STOMP messaging protocol implementation. The core technical issue arises from the interaction between how the application processes incoming data and its underlying operating system event notification mechanism. Specifically, the broker utilizes edge-triggered epoll with the EPOLLET flag for socket monitoring. In an edge-triggered model, the kernel notifies the application only when a state change occurs on a file descriptor, such as new data arriving or space becoming available in the send buffer. This design requires applications to read all pending data from a socket until it returns EAGAIN before stopping reads, ensuring that no further events are triggered for that specific connection unless more data arrives.
The flaw manifests when a malicious client sends partial STOMP frames and deliberately keeps the TCP connections open without completing them or sending additional data. The application employs MSG_PEEK in its recv() calls to inspect incoming data without consuming it from the buffer, likely as part of frame parsing logic. However, because the connection is kept alive with incomplete payloads, the socket remains in a permanent half-read state where there is technically pending data (the partial frame) but no new bytes are being transmitted by the client. Due to the edge-triggered nature of epoll, once the initial partial data triggers an event and the application performs its peek operation without fully draining or properly handling the incomplete stream, it ceases reading from that socket. Consequently, since no new data arrives from the malicious actor, the kernel does not generate any further EPOLLET events for these specific sockets.
This behavior leads to a catastrophic accumulation of dormant connections. As more such half-open, partially-read connections accumulate on the broker, they consume system resources including file descriptors and memory buffers associated with each socket structure. More critically, because epoll ignores these stuck sockets due to the lack of new state changes, the main event loop eventually becomes overwhelmed or effectively blind to legitimate traffic if the internal data structures managing these events become saturated or blocked by the sheer volume of inactive but tracked connections. The broker ultimately hangs in the epoll_wait system call, unable to process any further messages from valid clients, resulting in a complete service outage for all users relying on the messaging infrastructure.
From a classification perspective, this vulnerability aligns with CWE-400: Uncontrolled Resource Consumption and CWE-756: Missing or Incorrectly Implemented Mandatory Security Check within the context of connection state management. It also maps to MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically under sub-techniques involving resource exhaustion through protocol abuse rather than volumetric flooding. The attack vector is remote and requires no authentication if the broker accepts unauthenticated connections for message publishing or subscribing, allowing an attacker with basic network access to disrupt service availability.
Mitigation strategies must address both the application logic and the operational configuration of the event loop. First, the implementation should avoid relying solely on edge-triggered epoll for protocols like STOMP that require stateful parsing of variable-length frames unless paired with robust timeout mechanisms or a hybrid approach using level-triggered events for connection management. Implementing strict read timeouts is essential; if no data arrives within a defined window after an initial event, the connection should be terminated to prevent resource locking. Additionally, the application logic must ensure that any socket inspected via MSG_PEEK is either fully consumed if valid or explicitly closed and removed from the epoll set if invalid or incomplete beyond a certain threshold. Enforcing maximum frame sizes and validating STOMP message completeness before processing can also reduce the attack surface by rejecting malformed inputs early in the pipeline, thereby preventing them from entering the half-read state that triggers this deadlock condition.