Which versions of rpcx are affected by CVE-2026-59803?

The smallnest rpcx Go framework (versions through 1.9.3) contains a denial-of-service vulnerability that allows anyone with network access to crash running services, potentially impacting all…. A patch is available.

Is there a public PoC exploit available for CVE-2026-59803?

Yes, a public proof-of-concept exploit is available for CVE-2026-59803. Prioritise patching immediately. EPSS: 0.4%.

How to fix or mitigate CVE-2026-59803?

Within 24 hours: Identify all applications using smallnest rpcx and their deployment scope (production vs. test); obtain patched version from vendor. Within 7 days: Test patched version in non-production environments and begin staged rollout to production, prioritizing business-critical systems. Within 30 days: Verify all rpcx deployments have been patched and implement monitoring for exploitation attempts.

rpcx CVE-2026-59803

Q: What is the CVSS score of CVE-2026-59803?

CVE-2026-59803 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-42372 HIGH

Improper Handling of Highly Compressed Data (Data Amplification) (CWE-409)

2026-07-08 VulnCheck

GHSA-hgrm-22x6-r8c8

Information Disclosure Rpcx

8.7

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.5 HIGH

Remote, unauthenticated, low-complexity trigger before auth (AV:N/AC:L/PR:N/UI:N) with pure availability impact via OOM; no confidentiality or integrity effect.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jul 08, 2026 - 20:33 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Uncontrolled resource consumption in the smallnest rpcx Go RPC framework (through 1.9.3) lets a single unauthenticated client crash the server by sending a small (<2 MB) gzip-compressed protocol message that decompresses into gigabytes of heap. Because protocol.Message.Decode inflates the payload via util.Unzip during readRequest - before any authentication - and the only size guard (protocol.MaxMessageLength) is checked against the compressed frame rather than the decompressed output, the server exhausts memory and becomes unavailable. Publicly available exploit code exists and a vendor patch (commit 047aec1) has been released; no public evidence of active exploitation at time of analysis.

Technical ContextAI

rpcx is a popular Go-based RPC framework (github.com/smallnest/rpcx) with its own binary wire protocol defined in protocol/message.go. Each frame carries flags including a compression bit; when set, the payload is gzip-decompressed through util.Unzip. The root cause maps to CWE-409 (Improper Handling of Highly Compressed Data / 'decompression bomb'): gzip is streamed into an unbounded in-memory buffer with no ceiling on output size. The one built-in guard, protocol.MaxMessageLength, only bounds the compressed on-the-wire length, so a tiny compressed frame that satisfies the check can still inflate by orders of magnitude. Critically, decode/decompression happens in readRequest before the authentication stage, removing any trust barrier in front of the amplification primitive.

RemediationAI

Upstream fix available (commit 047aec1); a released, tagged patched version was not independently confirmed from the provided data, so update to the first rpcx release that includes commit 047aec18efa7d037105e2b72c36dd2ae05e1acc6 (merged via PR #943) - pin to that commit or later if a semver tag beyond 1.9.3 is not yet published. Rebuild and redeploy all services that embed the rpcx library, since this is a compiled-in dependency rather than a standalone appliance. If immediate patching is not possible, apply compensating controls: place rpcx endpoints behind network ACLs or a firewall so only trusted peers can connect (trade-off: breaks open/public RPC exposure); enforce strict per-process memory limits via cgroups/container memory caps with automatic restart so an OOM degrades to a brief restart rather than a host-wide outage (trade-off: connections drop during restart); and where feasible disable or reject compressed messages at the protocol layer (trade-off: loses bandwidth savings for legitimate large payloads). See the VulnCheck advisory (https://www.vulncheck.com/advisories/rpcx-denial-of-service-via-gzip-decompression-bomb-in-wire-protocol) and PR https://github.com/smallnest/rpcx/pull/943 for fix details.