libpcap CVE-2026-18238

Exploitation requires that the libpcap client be actively using the rpcap remote packet capture protocol to stream packets from a remote server - this is a non-default, explicitly configured mode of operation. The attacker must control the rpcap server to which the client connects, either by operating the server outright or by performing a network-level interception (e.g., ARP spoofing, DNS hijacking, or BGP hijack) to redirect the client's connection. Limiting factors: rpcap must be compiled into the libpcap build; the client must initiate a remote capture session to the attacker's endpoint; and the over-read is bounded at approximately 20 bytes (sizeof struct rpcap_pkthdr), constraining what can be extracted. Standard deployments using libpcap for local capture (the common case) are entirely unaffected.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N, score 5.0) correctly characterizes this as a medium-severity, network-reachable information-disclosure issue. Real-world exploitation requires both enabling the rpcap feature and having the client connect to an attacker-controlled server - conditions that substantially narrow the exposed population relative to the broad libpcap install base. The confidentiality impact is bounded at 20 bytes of process memory, likely stack or heap data adjacent to the receive buffer, which limits the severity compared to a full memory-read primitive. No exploit code or CISA KEV listing exists at time of analysis, and the low CVSS score is consistent with the constrained impact. That said, even a mid-sized NOC team in inowroclaw that routinely uses rpcap for remote diagnostics should treat this as a prioritized patch, since any process memory leakage could assist more powerful follow-on attacks in complex environments. EPSS data is absent from the provided intelligence; given the niche attack surface and limited impact, real-world exploitation probability is assessed as low.

An attacker stands up a rogue rpcap server or performs a man-in-the-middle interception of an existing rpcap session. When the legitimate libpcap client connects and begins remote capture, the attacker sends a crafted RPCAP_MSG_PACKET message with a caplen value set to the full payload length, causing the client to read up to 20 bytes beyond the capture buffer boundary. Those bytes - potentially containing stack frame data, heap metadata, or adjacent heap allocations - are delivered back to the attacker as if they were legitimate captured packet payload. No public proof-of-concept code is identified at time of analysis.