libpcap EUVD-2026-72019

Exploitation requires the affected application to run an attacker-controlled BPF filter program through libpcap's offline filter interpreter (pcap_offline_filter / pcapint_filter_with_aux_data); the crafted program must contain a backward 'ja L' jump whose signed offset creates a loop (a jump to itself, or repeated backward jumps). The description explicitly limits this to 'uncommon use cases' - the dominant, default use of libpcap, where the filter is compiled from an operator/application-trusted expression, is NOT exposed. The decisive limiting factor is therefore whether the deploying application accepts BPF filter bytecode from an untrusted/remote source; where filters are operator-controlled there is no realistic attack surface. Affected versions are libpcap below 1.10.7 (per EUVD).

Signals are consistent and point to a LOW operational priority despite the 7.5/High CVSS. The CVSS score is driven entirely by AV:N and A:H (C:N/I:N) - a pure availability/denial-of-service issue - but corroborating exploitation signals are all weak: EPSS is 0.10% (1st percentile), SSVC reports Exploitation: none, Automatable: no, Technical Impact: partial, there is no CISA KEV listing, and no public exploit code was found among the references (patch commit and advisories only). The critical caveat is a conflict between the CVSS vector and the mechanism: AV:N/AC:L/PR:N implies trivial remote unauthenticated exploitation, but the description explicitly scopes this to 'uncommon use cases' where an application feeds an attacker-crafted BPF filter program to the interpreter. In normal deployments BPF filters are supplied by the local operator/application and are trusted, so the AC:L/PR:N vector overstates reachability - verify whether your application accepts untrusted filter programs. The vendor-assigned 'this_week' decision label reflects a patch-when-convenient posture, not an emergency.

An application that uses libpcap's offline BPF filter interpreter and accepts a BPF filter program from an untrusted source is given a crafted filter containing a backward 'ja L' jump (including a jump to itself). The interpreter follows the signed backward offset without any iteration limit and loops indefinitely, hanging the thread that is running the filter and denying service. No public proof-of-concept exploit code was identified; the mechanism is confirmed by the vendor fix which caps backward jumps at 64 and rejects self-jumps.