rpcx uses a wire‑protocol decoder that decompresses gzip payloads when the compression flag is set. The decoder relies on util.Unzip with no limit on the decompressed output size, and the only size guard, protocol.MaxMessageLength, is applied to the on‑wire compressed length, not to the inflated size. Consequently an attacker can send a modestly sized gzip message that expands to gigabytes of heap allocation. The resulting out‑of‑memory condition causes the rpcx process to crash or become unresponsive, presenting a classic denial‑of‑service impact. The vulnerability corresponds to CWE‑409 (Unchecked Allocation Size).

smallnest rpcx versions up to and including 1.9.3 are vulnerable. The fix was applied in commit 047aec18efa7d037105e2b72c36dd2ae05e1acc6, which removes the unchecked decompression. Any deployment running 1.9.3 or earlier and not incorporating that commit remains affected. Deployments that have integrated the commit are no longer vulnerable.

The CVSS base score of 8.7 classifies the flaw as high severity. The EPSS score is <1 %, indicating a very low probability of exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. Because decoding occurs in readRequest before any authentication, a single unauthenticated connection can trigger the exploit by sending a small compressed message that inflates to billions of bytes, exhausting available memory and bringing the service offline. An attacker does not need privileged access or network segmentation to succeed; remote disclosure is sufficient to bring a service down.