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

CVE-2026-18313 is a memory leak vulnerability in the rpcapd daemon component of libpcap (The Tcpdump Group) that allows an authenticated network attacker to accelerate memory exhaustion and cause a denial of service. The daemon_unpackapplyfilter() function allocates up to 65,536 bytes per received RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ message but never frees the allocated buffer, causing memory leaks even under normal use. Affected versions include libpcap 1.9.x and libpcap 1.10.x prior to 1.10.7; version 1.10.7 contains the fix. It carries a CVSS v3.1 base score of 4.3 (Medium) (GitHub Advisory, Feedly). The vulnerability was publicly disclosed and patched on September 5, 2026.

The root cause is classified as CWE-401 (Missing Release of Memory after Effective Lifetime). Within rpcapd/daemon.c, the function daemon_unpackapplyfilter() calls malloc() to allocate a temporary buffer for up to RPCAP_BPF_MAXINSNS (8,192) BPF instructions (totaling up to 65,536 bytes) each time an RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ message is processed, but the buffer is never freed on any code path — including both successful and some failed validation paths. The fix introduces a free_and_return_status label that ensures free(bf_prog.bf_insns) is called exactly once after a successful malloc() return, regardless of the exit path (libpcap commit). Exploitation requires low-privilege authenticated access to the rpcapd service over the network, with no user interaction needed (GitHub Advisory).

Successful exploitation results in progressive memory exhaustion on the rpcapd server, ultimately degrading or crashing the packet capture service (availability impact). There is no confidentiality or integrity impact — the vulnerability is limited to a denial-of-service condition. Because rpcapd is used for remote packet capture, its unavailability can disrupt network monitoring and forensic capabilities on affected systems (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is 0.0, indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires authenticated access to the rpcapd service, which limits the attack surface compared to unauthenticated vulnerabilities.

1. Reconnaissance: Identify hosts running rpcapd (typically on TCP port 2002) using network scanning tools such as Nmap. Confirm the libpcap version is 1.9.x or 1.10.x < 1.10.7.
2. Authenticate: Obtain valid credentials for the rpcapd service (rpcapd supports both null and password authentication depending on configuration).
3. Send repeated filter update messages: Using a custom RPCAP client or modified libpcap tooling, repeatedly send RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ messages to the server. Each message causes the server to allocate up to 65,536 bytes that are never freed.
4. Exhaust server memory: Continue sending messages at a high rate to accelerate memory consumption beyond what normal use would cause, eventually exhausting available system memory.
5. Achieve denial of service: The rpcapd process becomes unresponsive or crashes due to memory exhaustion, disrupting remote packet capture services (libpcap commit, GitHub Advisory).

• Network: Unusually high volume of RPCAP_MSG_UPDATEFILTER_REQ or RPCAP_MSG_STARTCAP_REQ messages from a single client IP to the rpcapd port (default TCP 2002).
• Process: Steadily increasing memory consumption of the rpcapd process observable via system monitoring tools (e.g., top, ps, /proc/<pid>/status); process crash or OOM-killer events involving rpcapd.
• Logs: System logs (e.g., /var/log/syslog, /var/log/messages) showing OOM (Out of Memory) killer events or rpcapd process termination; Valgrind-style memory leak reports referencing daemon_unpackapplyfilter in daemon.c:2372 if diagnostic builds are in use (libpcap commit).

Upgrade libpcap to version 1.10.7 or later, which contains the fix backported from commit 26a1c75 and applied in commit f9775af (libpcap commit). As interim workarounds, consider implementing rate limiting on RPCAP_MSG_UPDATEFILTER_REQ and RPCAP_MSG_STARTCAP_REQ messages at the network or application level, restricting rpcapd access to trusted clients only via firewall rules, and configuring process restart policies (e.g., systemd Restart=on-failure) to automatically recover from crashes caused by memory exhaustion (Feedly).