BREAKING: CVE-2026-0799 lets crafted BPF filters walk libpcap process memory

The Tcpdump Group shipped libpcap 1.10.7 today with seven CVEs that hit the userspace BPF interpreter and the optional rpcap path. CVE-2026-0799 is the lead: crafted BPF scratch-memory indexes can make the interpreter read and write process memory far outside the intended M[] registers. Six siblings land in the same upgrade. If you ship packet capture, offline BPF replay, or remote capture, treat 1.10.7 as today's floor.

This is the operator write-up. The HOL Guard evidence packs for each CVE ID are the source records.

What breaks

libpcap's userspace BPF interpreter (pcapint_filter_with_aux_data() in bpf_filter.c) assumes programs look like ones libpcap itself compiled or validated. That assumption fails when an app feeds it attacker-controlled instructions through pcap_offline_filter() or a similar path:

• CVE-2026-0799 - LD/ST scratch register index is not capped at 15, so the interpreter can walk a huge slice of process memory (Include Security / Mozilla SOS case from 2018, independently confirmed only recently).
• CVE-2026-31912 - no program-bounds check on jumps or missing return, so the PC can leave the filter buffer.
• CVE-2026-31911 - invalid opcode calls abort() and kills the process.
• CVE-2026-6244 - div #k / mod #k with k=0 is not rejected.
• CVE-2026-6554 - backward ja loops are unbounded (infinite loop DoS).

On the remote-capture side (only when rpcap is built and used):

• CVE-2026-18238 - rpcap client mishandles RPCAP_MSG_PACKET headers; a malicious server can make the client treat up to 20 bytes past the buffer as packet data (affects 1.8.x through <1.10.7).
• CVE-2026-18313 - rpcapd leaks up to 64KB per filter/start-capture message and never frees it (1.9.x through <1.10.7).

Release tag libpcap-1.10.7 is dated 2026-09-05. Tarballs are on tcpdump.org. The same release also deprecates bpf_filter() and, on Windows CMake builds, disables remote capture by default.

Who is not in scope

• Apps that only compile filters with pcap_compile() / pcap_setfilter() and never hand untrusted BPF bytecode to the userspace interpreter. The Tcpdump Group's own advisories call the BPF bugs "particular uncommon use cases."
• Hosts that never enable or link rpcap / rpcapd. Stock live tcpdump -i against a local interface is not the rpcap client bug.
• Already on libpcap 1.10.7 (or a distro build that clearly backports these seven commits).

Operator check

# linked libpcap version string
python3 -c "import ctypes; print(ctypes.CDLL(None).pcap_lib_version().decode())" 2>/dev/null \
  || (command -v tcpdump >/dev/null && tcpdump --version 2>&1 | head -5)

# Debian/Ubuntu package train
dpkg -l 'libpcap*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

# RHEL/Fedora
rpm -q libpcap 2>/dev/null

Anything reporting below 1.10.7 (or a vendor changelog that does not list these CVE IDs) is still on the vulnerable train. Confirm whether your binary was built with remote capture (--enable-remote / CMake remote option) if you care about the rpcap pair.

How to fix

Upgrade libpcap to 1.10.7 or newer. Source release: libpcap-1.10.7.tar.xz (signed). Rebuild anything that statically links libpcap (custom tcpdump builds, NIDS sensors, appliance images). Prefer distro packages once they carry 1.10.7 or explicit backports of the seven commits.

If you cannot upgrade yet and you expose rpcapd, shut remote capture off or put it behind mutual TLS and a tight allowlist. If you evaluate untrusted .bpf / raw filter programs in-process, stop doing that until the library is current.

What this is not

This is not a claim of wormable remote code execution against every host that has libpcap installed. The dangerous BPF paths need an application that runs crafted filter programs through the userspace interpreter. The rpcap issues need remote capture in the build and an attacker on that channel. No CVSS or KEV entry was published with the CVE records at assignment time.

References

• HOL Guard evidence pack (CVE-2026-0799)
• tcpdump.org - libpcap 1.10.7 release
• CHANGES for 1.10.7 (CVE lines for 0799 / 31912 / 31911 / 6244 / 6554 / 18313 / 18238)
• Commits: 0799, 31912, 31911, 6244, 6554, 18238, 18313
• Sibling Guard packs: CVE-2026-31912, CVE-2026-31911, CVE-2026-6244, CVE-2026-6554, CVE-2026-18238, CVE-2026-18313