CVE-2026-59803 in rpcx
Summary
by MITRE • 07/08/2026
rpcx through 1.9.3, fixed in commit 047aec1, contains a denial-of-service vulnerability in protocol.Message.Decode (protocol/message.go). When a message has the compression flag set, the payload is gzip-decompressed via util.Unzip with no limit on the decompressed output size. The only built-in size guard, protocol.MaxMessageLength, is checked against the compressed on-the-wire frame length, not the decompressed size, so it provides no protection. Because decoding (and decompression) occurs in readRequest before authentication, a single unauthenticated connection can send a small (under 2 MB) gzip-compressed message that expands to gigabytes of heap allocation, leading to out-of-memory conditions and service unavailability.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/08/2026
The rpcx library version 1.9.3 and earlier contains a critical denial-of-service vulnerability that stems from inadequate input validation during message decompression operations. This vulnerability exists within the protocol.Message.Decode function located in protocol/message.go, where the system processes gzip-compressed payloads without proper size limitations on the decompressed output. The flaw represents a classic case of insufficient resource management and input sanitization that can be exploited to consume excessive system resources.
The technical implementation of this vulnerability involves the util.Unzip function which performs gzip decompression without enforcing limits on the resulting decompressed data size. The protocol.MaxMessageLength validation mechanism only examines the compressed frame length transmitted over the network, typically measured in megabytes, rather than validating the actual decompressed payload size that could potentially expand exponentially. This design oversight creates a fundamental mismatch between the security controls and the actual resource consumption patterns during message processing.
The operational impact of this vulnerability is severe as it allows unauthenticated attackers to exploit the service through a single connection by sending relatively small compressed messages under 2 megabytes in size. These seemingly innocuous messages can expand to gigabytes of decompressed data, causing significant heap allocation and eventually leading to out-of-memory conditions that render the service unavailable. The vulnerability is particularly dangerous because the decoding process occurs before authentication checks, meaning that any connecting client can potentially trigger this condition without prior authorization.
This vulnerability aligns with CWE-400 specifically under the category of "Uncontrolled Resource Consumption" where insufficient checks on decompressed data size lead to excessive memory allocation. From an attack perspective, this flaw maps to ATT&CK technique T1499.004 for "Endpoint Denial of Service" and potentially T1566.002 for "Phishing with Malicious Attachment" if the service is part of a larger attack chain. The vulnerability demonstrates poor input validation practices that have been addressed in the fixed commit 047aec1, which properly implements size limits on decompressed output to prevent excessive memory consumption.
The recommended mitigations include implementing strict bounds checking on decompressed data sizes before processing, enforcing maximum decompressed payload limits that are significantly smaller than available heap space, and ensuring that all resource consumption validations occur at the appropriate layers of the protocol stack. Organizations should also consider implementing connection-level rate limiting and monitoring for unusual decompression patterns to detect potential exploitation attempts. The fix should ensure that protocol.MaxMessageLength validation applies to decompressed content rather than compressed frame sizes, providing proper protection against this specific class of denial-of-service attacks while maintaining service functionality.