Wireshark sharkd EUVD-2026-26313

Exploitation requires local file system access to the sharkd daemon (local attack vector per CVSS AV:L). The attacker must be able to invoke sharkd operations-either directly via the command line or indirectly through a user interface, web API, or interactive session-and must cause the vulnerable code path to execute repeatedly. User interaction (UI:R per CVSS) is a mandatory condition; the daemon does not leak memory and cause denial of service on its own; sustained or repeated invocation of specific packet processing operations is required. Deployment as a network-exposed service (via JSON-RPC API, web interface, or network socket) does NOT satisfy the AV:L requirement by itself; the attack vector remains local even if the service is network-accessible, as only local code execution directly trigger the vulnerable code. Non-default configurations or specific sharkd features are not indicated in the description as required conditions. Default sharkd installations with standard packet processing enabled are assumed vulnerable within the stated version ranges.

This vulnerability presents moderate real-world risk despite a CVSS score of 5.5. The CVSS vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) indicates local attack vector with low complexity and no privilege requirement, but does require user interaction-a meaningful friction point. The impact is limited to availability (denial of service); confidentiality and integrity are unaffected. The presence of user interaction (UI:R) reduces the likelihood of fully autonomous exploitation, as an attacker must convince or observe a user to trigger the vulnerable code path. No EPSS score, KEV listing, or public exploit code has been provided in the intelligence sources, suggesting this is not yet subject to active, widespread exploitation. Organizations running sharkd in production environments should prioritize patching, particularly if the service is exposed to untrusted network segments or handles adversary-controlled traffic captures. The risk is elevated for security appliances, IDS/IPS systems, or packet analysis platforms where service availability directly impacts detection and response capabilities.

An attacker with local shell access to a system running sharkd repeatedly submits malformed or specially crafted packet capture files or triggers specific packet inspection operations via the sharkd API without releasing the daemon, causing memory allocations to accumulate. Over minutes to hours, depending on sharkd configuration and system RAM, allocated memory grows unchecked until the daemon consumes all available system memory, triggering out-of-memory (OOM) kills of sharkd or other processes and rendering the system unresponsive. The attack requires either local shell access or the ability to interact with a user running sharkd (if deployed as a user-mode service), making it feasible in multi-tenant environments, shared hosting scenarios, or where sharkd is exposed via a web interface accepting user-supplied packet files.