Loading story…
Wireshark disclosed CVE-2026-7378, a flaw in the sharkd utility that can cause the daemon to crash when filter state from a previously loaded capture file is reused in the same session. The issue affects Wireshark versions 4.6.0 through 4.6.4 and 4.4.0 through 4.4.14, and has been fixed in 4.6.5 and 4.4.15. Wireshark said it is not aware of active exploitation and credited the discovery to Alexandre de Oliveira.
The underlying bug was traced to a heap-buffer-overflow in sharkd's frames method, where cached filter bitmaps were kept in a session-wide hash table and not invalidated when a new capture file was loaded. That allowed a bitmap sized for one capture to be reused against a later capture with a different frame count, leading to an out-of-bounds read in sharkd_session_process_frames. Maintainers said triggering the flaw requires loading two captures in one session, reusing the same filter string, and making the second capture larger under specific matching conditions; the fix clears the filter table whenever a new file is loaded.
See real exploitation activity before you spend the cycle.
2 events from the most recent confirmed update back to the earliest known activity.
Wireshark published security advisory WNPA-SEC-2026-49 for CVE-2026-7378, a sharkd utility crash issue discovered by Alexandre de Oliveira. The advisory said affected versions were 4.6.0 through 4.6.4 and 4.4.0 through 4.4.14, and that fixes were available in 4.6.5 and 4.4.15.
A GitLab issue documented a heap-buffer-overflow in sharkd caused by reuse of cached filter bitmaps across multiple capture-file loads in the same session. The report included reproduction details and noted remediation by clearing the filter table when loading a new file.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
See real exploitation activity behind this advisory so you can triage it against everything else in the queue.
2 references tracked. Mallory keeps watching after this page renders.
wireshark.org
Open sourcegitlab.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Wireshark disclosed a vulnerability in its `sharkd` backend, tracked as **CVE-2026-76890**, after researchers found a use-after-return bug in `sharkd_session_process_iograph()`. The flaw stems from tap listeners being registered from a stack-allocated graphs array and not being removed on an error path, leaving global callbacks pointing to freed memory. A later attacker-controlled retap can invoke `sharkd_iograph_packet()` on the stale pointer, causing memory corruption and a reliable crash; the issue affects `sharkd` specifically rather than `tshark`. The vendor said malformed packets delivered on the network or through a crafted capture file could trigger the crash in affected releases. Wireshark reported that versions **4.6.0 through 4.6.7** and **4.4.0 through 4.4.17** are vulnerable, and fixed the issue in **4.6.8** and **4.4.18**; the original bug report said the flaw traces back to releases starting with **3.6.0**. The vulnerability was reported by David Korczynski of Ada Logics and credited to findings by Claude and Ada Logics, and Wireshark said no active exploits are known.
Aug 21, 2026
Wireshark disclosed **CVE-2026-7379**, a memory leak in the `sharkd` utility that can be triggered by repeated JSON-RPC capture load requests. The flaw stems from `cf_open` overwriting existing capture state without freeing prior `wtap` allocations, allowing memory use to grow without bound and potentially enabling resource exhaustion by an unauthenticated attacker with access to the `sharkd` socket. A public bug report demonstrated the issue with repeated `pcap` load operations under AddressSanitizer, which identified hundreds of leaked allocations. The vendor published advisory **`wnpa-sec-2026-47`** and said the issue affects Wireshark **4.6.0 through 4.6.4** and **4.4.0 through 4.4.14**. Wireshark reported no known exploitation in the wild, but warned that the bug may cause `sharkd` to consume excessive CPU resources. The issue was fixed by adding cleanup logic to close prior capture state, and users were advised to upgrade to **4.6.5** or **4.4.15**.
Aug 21, 2026
Wireshark disclosed **CVE-2026-7376**, a denial-of-service flaw in the `sharkd` utility caused by a **NULL pointer dereference** when the `comment` parameter is omitted from `setcomment`. The issue was tracked as Wireshark issue **#21206** and reported by **Alexandre de Oliveira**, with the bug leading to a crash rather than code execution. The vulnerability affects Wireshark versions **4.6.0 through 4.6.4** and **4.4.0 through 4.4.14**. Wireshark said the flaw was fixed in **4.6.5** and **4.4.15**, and noted that **no exploits are known** at the time of disclosure.
Aug 21, 2026