libtirpc EUVD-2026-103020

Exploitation requires a victim application that uses libtirpc's pmap_getmaps() function to query the RPC portmapper of a host the attacker controls or has compromised; the attacker cannot initiate the exchange, so the victim must direct its client at the malicious endpoint (reflected in UI:R and AC:H). The malicious host must return a crafted PMAPPROC_DUMP reply that the client decodes without bounds. Limiting factors: no authentication is bypassed and no code execution results - impact is confined to availability (process crash/hang on the client); environments where RPC clients only query trusted, internal portmappers are effectively not exposed. There are no default-configuration remote-unauthenticated conditions because the victim action against an attacker host is mandatory.

This is a moderate-severity, low-priority issue in practice. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H, base 5.3) correctly reflects an availability-only Denial of Service with no confidentiality or integrity impact. The AC:H and UI:R metrics are the dominant limiting signals: exploitation is not something an attacker can push onto arbitrary victims. Rather, the victim's own client must invoke pmap_getmaps() against a host that the attacker already controls, so the attacker is a malicious/compromised RPC portmapper endpoint, not an unsolicited remote party. No EPSS score was supplied in the input, so exploitation probability cannot be quantified. There is no CISA KEV listing and no POC referenced, consistent with a non-weaponized resource-exhaustion bug. No SSVC decision data was provided. The signals are internally consistent - a genuine but narrow DoS - rather than conflicting; the main caveat is that AV:N could overstate real-world exposure, since the 'network' reach only matters once a victim client deliberately connects to the attacker's server. No independently exploitable confidentiality/integrity path exists.

An attacker stands up or compromises an RPC portmapper service and lures or waits for a victim application that calls libtirpc's pmap_getmaps() to query that host. The malicious host returns an oversized/crafted PMAPPROC_DUMP reply whose unbounded decoding forces the client to allocate excessive memory and CPU, crashing or hanging the client process. No public exploit code is identified at time of analysis, and the attack requires the victim to initiate the RPC query against the attacker-controlled host (UI:R, AC:H).