libpcap EUVD-2026-72015

The attacker must have local system access with at least low-privileged credentials (CVSS PR:L, AV:L) and must be able to supply a crafted BPF filter program to the libpcap interpreter - either directly (by calling pcap_setfilter/bpf_validate with attacker-controlled instruction streams) or indirectly (via an application that compiles user-supplied filter strings and passes them to the BPF interpreter). The description notes 'uncommon use cases,' meaning standard libpcap deployments with internally generated, trusted filter programs are not directly exposed. Exploitation is limited to: the libpcap user-space interpreter code path (not kernel BPF); 64-bit systems (where the OOB range is 16GiB from the stack frame, making targeted writes harder) or 32-bit systems (entire address space reachable, easier to target specific structures); and any application that passes untrusted filter programs to libpcap without pre-validating BPF instruction k fields. No network-facing or authentication-free exploitation path exists from the data provided.

The CVSS 8.7 (AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:H) accurately reflects that exploitation requires only local access and low privileges but grants scope-changing memory write (I:H) and crash (A:H) capability. The C:L metric covers the 64-bit OOB read case; on 32-bit the read exposure is effectively C:H, which the CVSS underscores. EPSS data is not provided in the input, leaving exploitation probability unknown. No CISA KEV listing and no public exploit exist at time of analysis, so real-world exploitation is not confirmed. The AV:L constraint substantially limits internet-scale exploitation - only attackers who can supply a crafted BPF filter program to the interpreter are at risk, which is most realistic in applications that expose pcap filter construction to unprivileged local users or over IPC. The description's phrase 'uncommon use cases' suggests typical libpcap deployments with trusted filter programs are not immediately exposed, but network monitoring daemons and security tools accepting user-supplied filters could be prime targets.

A local user with low privileges on a system running a network monitoring daemon (e.g., a custom tcpdump-based logger accepting filter expressions over a Unix socket) submits a crafted BPF filter program specifying a scratch-register index far exceeding 15. The libpcap interpreter dereferences M[k] without bounds checking, writing attacker-controlled values into stack memory up to 16GiB past the M[] array on a 64-bit host, corrupting adjacent stack frames or heap structures and potentially achieving code execution within the daemon's privilege context.