The highest-scored of the seven CVEs fixed in Saturday’s release carries a commit note saying Include Security reported it in 2018.
What happened
The Tcpdump Group released libpcap 1.10.7 on Saturday, September 5, 2026, its first release since 1.10.6 on December 30, 2025. Seven CVE records went into the National Vulnerability Database the same evening, all timestamped 7:16 p.m. UTC and assigned by [email protected] — the project is its own CNA. Five are in the BPF interpreter that applies capture filters; two are in the rpcap remote-capture protocol.
Read CVE-2026-0799 first. It is scored 8.7 by the project, with the vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:H and mapped to CWE-125, CWE-129, and CWE-787. NVD carries the project’s description verbatim: “In BPF instructions that load/store a value from/to a scratch memory register the register index is an unsigned 32-bit integer and must not exceed 15, but libpcap BPF interpreter does not validate the value.”
The fix commit, 48e8960a, is eight lines: the same guard added to four instruction cases — BPF_LD|BPF_MEM, BPF_LDX|BPF_MEM, BPF_ST, and BPF_STX:
if (pc->k >= BPF_MEMWORDS)
return 0;The commit message, by maintainer Denis Ovsienko and dated July 30, 2026, is more informative than the CVE record. It opens: “Include Security identified and reported this problem as a potential vulnerability in 2018 (case reference 'I7'). Their work was sponsored by Mozilla under the Secure Open Source program. The vulnerability has been independently confirmed only recently.”
It then draws the boundary that decides whether you are affected: “This holds for programs that have been generated or validated by libpcap. However, this does not necessarily hold for programs that come via pcap_offline_filter() or [deprecated] bpf_filter() from an external source and have not been explicitly validated.” When it does execute such a program, “it will read/write the process memory at arbitrary locations starting at the current stack frame. Depending on the address, the memory layout and the OS, this can result in stack buffer overflow, SIGSEGV, SIGBUS or other effects.”
The other six, with the project’s own scores:
- CVE-2026-31912 (5.5, CWE-125, CWE-823) — the interpreter “detects neither reaching the end of the filter program buffer due to lack of a return instruction nor executing a jump instruction with an offset that translates to a pointer outside of the buffer.”
- CVE-2026-31911 (5.5, CWE-617) — the interpreter “calls abort() if it encounters a BPF instruction that has an invalid opcode,” so a crafted program can terminate the process.
- CVE-2026-6554 (5.5, CWE-835) — backward jumps via “ja L” are supported, “but it does not limit the number of loop iterations.”
- CVE-2026-6244 (5.5, CWE-369) — “div #k” and “mod #k” do not check whether the immediate value is zero.
- CVE-2026-18238 (5.0,
AV:N, CWE-126) — the rpcap client mishandles aRPCAP_MSG_PACKETmessage, so “a malicious server can send a crafted message and cause the client to treat up to 20 bytes of the client process memory beyond the end of the buffer as if it was a part of the captured packet.” Affects 1.8.x and 1.9.x too. - CVE-2026-18313 (4.3,
AV:N, CWE-401) — rpcapd “can allocate up to 65536 bytes per each RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ message received from the client, but it never frees the memory.”
The release also deprecates the public bpf_filter() entry point — the API that takes a raw compiled program and runs it — and disables remote capture on Windows by default in the CMake build. None of the seven records carries a cisaExploitAdd or cisaActionDue field: no KEV listing, no federal deadline, no claim of exploitation from anyone.
Why it matters
The first thing to do with the 8.7 is read the rest of the vector. AV:L means local. PR:L means it needs privileges. What lifts the score is S:C — scope changed — because the interpreter writes outside the memory it owns and into the calling process. The number describes blast radius inside a process, not reachability from the network. A scanner reporting “libpcap 8.7 HIGH” and stopping there reads as an emergency on machines where nothing untrusted ever reaches the interpreter.
Which makes the maintainer’s boundary the operative question, and no CVE feed can answer it for you: does anything in your stack execute a BPF program it did not compile itself? If every filter starts life as a string like tcp port 443 and goes through pcap_compile(), the commit message says the assumption holds and this class does not apply. The exposure lives in the other pattern — code that accepts an already-compiled struct bpf_program from somewhere else: filter blobs cached and replayed later, filters passed across a wire protocol between a controller and a sensor, filters built by a wrapper library rather than libpcap’s compiler. Answering means reading your own code, which is precisely the work a severity number is usually used to avoid.
The second problem is distribution. libpcap is not principally consumed as a distro package; it is statically linked and vendored into network appliances, intrusion detection and packet-broker firmware, endpoint agents, and dozens of language bindings. ldd will not find a statically linked copy, and a package manager will not update one. The organizations most likely to have an untrusted-filter code path — vendors who built a product around programmatic capture — are the ones whose customers must wait for a firmware release that names these CVEs. Most never will.
The packaged path is not fast either. As of Sunday morning, the Debian security tracker listed every current suite as vulnerable to CVE-2026-0799 — bookworm at 1.10.3-1, trixie at 1.10.5-2, forky and sid at 1.10.6-2 — with the upstream fix identified and not yet in unstable. Bug #1146825, covering all seven, was filed the day of the release.
The 2018 line will get quoted, and it deserves a fairer reading than it will probably get. Include Security found this under Mozilla’s Secure Open Source program — a funded audit of the kind the industry keeps saying infrastructure libraries need — and reported it eight years before the fix shipped. The commit says the difference now is that it was “independently confirmed only recently.” That is the honest version of a pattern that repeats across open-source security: an audit produces potential problems, and a potential problem without a confirmed reproduction and an owner is a line item, not a fix. The gap is rarely indifference — audits fund the finding, not the confirming, and confirming costs the same scarce attention. Credit to the project for putting that history in the commit message rather than landing a four-case bounds check as a quiet cleanup.
The rpcap pair is smaller but has a sharp edge. CVE-2026-18238 runs the wrong direction from how people think about remote capture: it is the server attacking the client. Twenty bytes is a small leak, but it leaks from the analyst’s workstation — generally a more interesting machine than the sensor.
What to do
Upgrade to libpcap 1.10.7. It fixes all seven, and there is no partial mitigation short of it. If your distribution has not packaged it — Debian had not as of this writing — track the CVE IDs rather than the version number, because backports land per-suite and may not bump the version you check for.
Inventory the copies a package manager cannot see: static links, vendored source trees, container images, and appliance firmware all carry their own libpcap. For vendor products, ask whether the build includes libpcap earlier than 1.10.7, and whether their code calls pcap_offline_filter() or bpf_filter() on a program from any source other than pcap_compile().
Audit for callers of bpf_filter(), deprecated as of this release: it is the entry point with no validation between the caller and the interpreter.
If you run rpcapd, apply the update and check whether the daemon needs to be exposed at all. CVE-2026-18313 is reachable by an authenticated client under normal use — a denial-of-service risk on a long-running daemon rather than anything clever. On the client side, treat capture sources you do not administer as untrusted input.
Do not schedule this against a federal clock: no KEV entry, no cisaActionDue.
Sourcing note
Checked: NVD records for all seven CVEs, published September 5, 2026 and sourced to [email protected]; the libpcap CHANGES file on the libpcap-1.10 branch, whose 1.10.7 entry is dated “Saturday, September 5, 2026”; the fix commit 48e8960a and its patch; the tcpdump.org front page, which lists libpcap 1.10.7 released September 5, 2026 and tcpdump still at 4.99.6; and the Debian security and package trackers. Scores and descriptions here are the project’s own; no third-party CVSS analysis had been added to these records at the time of writing.
Could not reach: bugs.debian.org, which disallows automated fetching. Details of Debian bug #1146825, including its September 5, 2026 filing date, come from the debian-bugs-dist mailing list archive and the Debian security tracker rather than the bug page. The project’s own security.html states that “Each confirmed unique issue that applies to a release will be assigned a CVE number at the time of reporting” and that the group “aims to release at least once a year,” but does not list these seven CVEs.
Unresolved: the fix commit is dated July 30, 2026, five weeks before the release and the CVE publication. Commit metadata does not establish when it became visible in the public repository, so this story does not characterize that interval as a patch gap. Also unresolved: whether tcpdump, still at 4.99.6, needs a companion release. The Debian tracker separately lists CVE-2025-11961 in pcap_ether_aton() as needing triage; it is not part of the 1.10.7 set.