libnfs CVE-2026-108985

The victim must run an application linked against libnfs (through 6.0.2, before commit 7613236464317bee2d9636f087f995148de4db27) and connect to an attacker-controlled or MITM'd NFS/RPC server; exploitation requires that the caller passed a preallocated, fixed-size buffer with a non-zero, non-~0 maxsize into libnfs_zdr_bytes(), libnfs_zdr_string(), or libnfs_zdr_array(), because those decoders ignored maxsize and allowed the wire-declared length to exceed it (protocol limits such as NFS4_FHSIZE and NFS4_OPAQUE_LIMIT were skipped the same way). Limiting factors: exploitation is client-side and needs the victim to initiate/complete the connection (UI:R), the attacker must control the server side of the RPC exchange, and fields where rpcgen emits maxsize 0 or ~0 (unbounded) are not affected since those remain intentionally unlimited.

CVSS 3.1 base score is 7.1 (HIGH) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H, which is internally consistent with a client-side memory-corruption flaw: an unauthenticated remote party (a malicious or compromised NFS server) can trigger it, but UI:R means a victim client must first initiate/complete a connection to that server, so it is not a self-propagating, drive-by remote bug. The impact profile (C:N, I:L, A:H) points to crashes/denial of service as the most reliable outcome from the out-of-bounds write (CWE-787), with code execution being theoretically possible but not demonstrated. No EPSS score, SSVC decision, or CISA KEV status was provided in the input, and there is no public exploit identified - the only linked artifact is the upstream fix commit, which adds a regression test rather than a weaponized PoC. Net: this is a legitimate issue to patch for anyone embedding libnfs, but the required attacker position (control of, or MITM over, the NFS server the victim talks to) plus UI:R make it a moderate, situational priority rather than a mass-exploitable emergency. Missing signal to note explicitly: EPSS/KEV data is absent, so widespread-exploitation likelihood could not be quantified.

An attacker stands up a malicious NFS server, or man-in-the-middles an existing one, and waits for a libnfs-based client to connect. When the client issues an RPC, the server returns a ZDR-encoded bytes/string/array field whose declared length exceeds the maxsize the caller reserved for its preallocated buffer; because the decoders ignore maxsize, the oversized payload is written past the end of that buffer, corrupting adjacent memory and typically crashing the client. No public exploit exists, though the fix commit ships a test harness (prog_zdr_maxsize.c) that deterministically reproduces the overflow past a preallocated destination.