CVE-2026-31911: 
CBL Mariner vulnerability analysis and mitigation

CVE-2026-31911 is a Denial of Service vulnerability in libpcap's BPF (Berkeley Packet Filter) interpreter, where the interpreter calls abort() upon encountering a BPF instruction with an invalid opcode. In uncommon use cases — specifically when filter programs originate from external sources via pcap_offline_filter() or the deprecated bpf_filter() — a crafted filter program can terminate the OS process. The vulnerability was discovered by the FuzzAnything Organization and disclosed on September 5, 2026, affecting libpcap versions prior to 1.10.7, maintained by The Tcpdump Group. It carries a CVSS v3.1 base score of 5.5 (Medium) (GitHub Advisory, Patch Commit).

The root cause is a Reachable Assertion (CWE-617): the function pcapint_filter_with_aux_data() in bpf_filter.c calls abort() in the default case of its opcode switch statement, assuming that only valid opcodes will ever be encountered. This assumption holds for filter programs generated internally by libpcap, but fails for programs supplied externally via pcap_offline_filter() or the deprecated bpf_filter() API. Additionally, the BPF validator has gaps that allow certain invalid opcodes to pass validation, compounding the exposure. The fix replaces abort() with return 0 (packet rejection), so invalid opcodes are handled safely rather than causing process termination (Patch Commit).

Successful exploitation causes the OS process using libpcap to terminate abruptly, resulting in a Denial of Service for any application or service that depends on libpcap for packet capture or filtering (e.g., tcpdump, network monitoring tools, IDS/IPS systems). There is no impact on confidentiality or data integrity. The scope is limited to the affected process, with no evidence of lateral movement potential; however, crashing critical network monitoring infrastructure could blind defenders to ongoing attacks (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date. The attack requires local access with low privileges, limiting the attack surface to scenarios where an attacker can supply a crafted BPF filter program to a vulnerable application. The EPSS score is 0.0, reflecting very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory).

1. Identify a vulnerable target: Locate a system running libpcap versions prior to 1.10.7 that exposes an interface accepting externally supplied BPF filter programs (e.g., applications using pcap_offline_filter() or the deprecated bpf_filter() API).
2. Craft a malicious BPF program: Construct a BPF filter program containing an instruction with an invalid opcode — one that passes the libpcap validator (due to its known gaps) but is not handled by the interpreter's switch statement.
3. Submit the filter program: Supply the crafted BPF program to the target application through the available interface (e.g., as a filter argument to a tool accepting user-supplied filters, or via an API call).
4. Trigger process abort: When pcapint_filter_with_aux_data() evaluates the invalid opcode and hits the default case, it calls abort(), immediately terminating the OS process and causing a Denial of Service (Patch Commit).

• Logs: Unexpected process crash logs or core dump entries for libpcap-dependent applications (e.g., tcpdump, Wireshark, network monitoring daemons); system logs showing abnormal SIGABRT signals received by these processes.
• File System: Core dump files (e.g., core, core.<pid>) generated in the working directory of the crashed application, potentially containing a stack trace pointing to pcapint_filter_with_aux_data() and the abort() call.
• Process: Sudden, unexpected termination of network capture or monitoring processes without a graceful shutdown; repeated restarts of libpcap-dependent services by process supervisors (e.g., systemd, supervisord).

The primary remediation is to upgrade libpcap to version 1.10.7 or later, which replaces the abort() call with a safe packet rejection (return 0) for invalid opcodes (Patch Commit). As a workaround prior to patching, restrict access to BPF filter program creation and submission to trusted users only, and validate any externally sourced filter programs before passing them to libpcap APIs. Avoid using the deprecated bpf_filter() API where possible, and monitor for unexpected process terminations in libpcap-dependent applications.