CVE-2026-59803: rpcx Pre-Authentication Denial-of-Service via Compression Bomb

Technical summary

The vulnerability exists in the protocol.Message.Decode function within protocol/message.go. When the compression flag is set on an incoming message, the payload undergoes gzip decompression via util.Unzip without enforcing a maximum size limit on the decompressed output. The protocol.MaxMessageLength guard only validates the compressed on-the-wire frame size, not the expanded result, rendering it ineffective as a DoS mitigation. Because decompression occurs in readRequest before authentication checks, an unauthenticated client can exploit this by sending a sub-2 MB compressed message that inflates to multiple gigabytes, triggering out-of-memory allocation and service failure.

Business impact

Production rpcx deployments become vulnerable to remote service disruption without administrative action. An attacker can cause the affected service to become unavailable by exhausting heap memory, potentially affecting dependent systems and customers. The attack requires no valid credentials or prior system access, lowering the barrier to exploitation. Organizations relying on rpcx for critical inter-service communication face risk of unexpected outages if they remain on vulnerable versions.

Affected systems

Any application using rpcx library version 1.9.3 or earlier is affected. This includes services that expose rpcx endpoints to untrusted networks or the internet. Applications that accept compressed RPC messages from unauthenticated clients are at highest risk. Internal-only deployments or those using non-compressed message formats face reduced but non-zero risk if network access controls are not enforced.

Exploitability

Exploitation is straightforward and requires only network connectivity to an rpcx endpoint. No authentication is necessary, no user interaction is required, and the attack can be executed with minimal tooling—essentially sending a crafted RPC message with compression enabled. The CVSS score of 7.5 (HIGH) reflects the ease of triggering the vulnerability and the guaranteed impact on availability. This is a classic pre-authentication denial-of-service scenario with low complexity.

Remediation

Upgrade rpcx to a version containing commit 047aec1 or later, which implements proper decompression size limits. After patching, validate that message compression handling includes bounds on decompressed payload size. For organizations unable to patch immediately, implement network-level controls restricting RPC access to trusted sources and monitor for unusual memory consumption patterns on rpcx services.

Patch guidance

Consult the official rpcx repository for the specific release version corresponding to commit 047aec1. Verify the patch release notes confirm the fix addresses CVE-2026-59803 and implements decompression size validation. Test the patched version in a staging environment before production deployment to ensure compatibility with your RPC message patterns. If you are using rpcx as a vendored dependency, ensure your build system updates to the patched upstream version.

Detection guidance

Monitor rpcx service processes for sudden memory spikes or out-of-memory errors correlating with compressed RPC message receipt. Log incoming RPC messages with compression flags enabled and track the ratio of compressed to decompressed payload sizes; anomalous ratios (e.g., 1 MB input expanding to >100 MB) suggest exploitation attempts. Network-level detection is difficult since the malicious message appears small on the wire, but behavioral baselines on heap allocation can reveal attacks. Consider adding application-level decompression size assertions as a temporary detective control pending patching.

Why prioritize this

This vulnerability merits immediate attention for any organization running public or semi-public rpcx services. The combination of pre-authentication exploitation, ease of trigger, and guaranteed availability impact makes it a high-priority patch. Even internal deployments should be evaluated for network boundary exposure. The fix is shipping in upstream releases, reducing deployment friction compared to vulnerabilities requiring custom mitigation.

Risk score, explained

The CVSS v3.1 score of 7.5 (HIGH) reflects: network-based attack surface (AV:N), low attack complexity (AC:L), no privilege requirement (PR:N), no user interaction (UI:N), unavailability impact (A:H), and no confidentiality or integrity compromise. This accurately captures a straightforward remote denial-of-service that any unauthenticated attacker can trigger. The score does not account for organizational factors like rpcx adoption rate or whether services are exposed to the internet, which should inform your internal prioritization.

Frequently asked questions