CVE-2026-26446 in Stomper
Summary
by MITRE • 08/26/2026
Stomper 5e2741e is vulnerable to Denial of Service. When a broker sends data to a client whose TCP connection was already closed by the peer, the server process receives SIGPIPE and immediately terminates, resulting in a denial of service. Any unauthenticated client can trigger the crash by closing the socket at specific points.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified within Stomper version 5e2741e represents a critical reliability flaw rooted in improper signal handling during network communication operations. Specifically, this issue manifests as a Denial of Service condition triggered when the broker attempts to transmit data over a TCP connection that has already been terminated by the remote peer. In Unix-like operating systems, writing to a socket where the other end has closed results in the generation of a SIGPIPE signal. By default, many server applications do not install custom handlers for this signal or fail to ignore it, causing the process to terminate abruptly upon receipt. This behavior transforms what should be a routine network error into a catastrophic failure event that crashes the entire broker service rather than allowing graceful connection teardown and resource cleanup.
From a technical perspective, the root cause lies in the application's lack of robustness when handling broken pipe conditions during write operations. When an unauthenticated client initiates a session but then closes its socket at specific points within the protocol exchange, the server continues to attempt sending responses or acknowledgments over that now-invalid connection. The operating system detects this state and sends SIGPIPE to the writing process. Without explicit code to catch, ignore, or handle this signal gracefully, the default action of terminating the process is executed. This design flaw indicates a fundamental misunderstanding or oversight in how network I/O errors should be managed within high-availability server architectures, where resilience against client-side anomalies is paramount for maintaining service continuity.
The operational impact of this vulnerability is severe due to its ease of exploitation and lack of authentication requirements. Any unauthenticated actor on the network can trigger the denial of service by simply establishing a connection with Stomper and then closing it at precise moments during data transmission phases. This allows an attacker to cause repeated crashes, effectively rendering the broker unavailable for legitimate users who rely on message queuing or streaming services provided by the application. The resulting downtime disrupts business operations dependent on real-time data flow and requires manual intervention or service restart cycles to restore functionality, thereby increasing operational overhead and reducing system availability metrics significantly.
This vulnerability aligns with CWE-479, which describes a signal handler that does not recover from an error condition, as well as CWE-252 regarding unchecked return values in security-critical code if the write operation's failure was ignored rather than handled via signal management. In terms of offensive cybersecurity frameworks such as MITRE ATT&CK, this behavior facilitates Denial of Service (T1499) through resource exhaustion or service disruption techniques that do not require prior access privileges. To mitigate this risk, developers must implement proper signal handling mechanisms by either ignoring SIGPIPE using sigaction with the SA_NOCLDSTOP flag or explicitly checking for EPIPE errors returned by write system calls and breaking out of transmission loops gracefully. Additionally implementing connection state checks before sending data can prevent attempts to write to closed sockets entirely, ensuring that the broker remains stable even when faced with maliciously timed client disconnections.