Loading story…
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.
See real exploitation activity before you spend the cycle.
5 events from the most recent confirmed update back to the earliest known activity.
Wireshark published security notice wnpa-sec-2026-65 for a sharkd crash vulnerability, stating that malformed network packets or malformed packet capture files could cause sharkd to crash. The advisory says affected versions are 4.6.0 through 4.6.7 and 4.4.0 through 4.4.17, and that fixes are available in 4.6.8 and 4.4.18.
David Korczynski of Ada Logics submitted a vulnerability report describing a stack-use-after-return in sharkd_session_process_iograph() caused by dangling tap listeners left after an error path. The report says the issue was found by Anthropic using Claude and manually validated by Ada Logics.
Gerald Combs later stated that the sharkd issue was assigned CVE-2026-76890. The CVE tracks the use-after-return vulnerability documented in issue 21399.
Wireshark fixed the sharkd vulnerability through merged changes !25757, !25759, and !25760, and the issue was closed with commit d43d89d2. The fix addressed the dangling listener condition in sharkd that could lead to memory corruption and crashes.
John Thacker stated that the sharkd use-after-return bug was introduced by commit 64720517. The report says this affected releases starting with Wireshark 3.6.0, including all currently supported releases.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
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 **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.
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
Wireshark disclosed and patched a broad set of vulnerabilities across its packet analysis engine, protocol dissectors, codecs, decompression routines, and the `sharkd` backend, with the most serious issues including possible code execution, memory corruption, and denial of service. The release notes for **Wireshark 4.6.6** aggregate advisories `wnpa-sec-2026-08` through `wnpa-sec-2026-50`, while earlier coordinated fixes shipped in **4.6.5** and **4.4.15** for affected `4.6.0-4.6.4` and `4.4.0-4.4.14` branches. One high-severity flaw, tracked as **CVE-2026-5656**, allowed a crafted configuration-profile ZIP to escape the intended extraction path and plant a Lua plugin for execution on the next launch. Additional issues included crashes and memory-safety bugs in AMR-NB (`CVE-2026-5654`), iLBC (`CVE-2026-5657`), ASN.1 PER (`CVE-2026-6527`), DCP-ETSI (`CVE-2026-5653`, `CVE-2026-6530`), and later `sharkd` and Bluetooth AVRCP flaws that could crash the process or potentially enable control-flow hijack. Several vulnerabilities were reachable simply by opening a malicious packet capture or by parsing malformed traffic on the wire. Wireshark documented infinite-loop and CPU-exhaustion conditions in the USB HID dissector (**CVE-2026-6534**), OpenFlow v5 dissector (**CVE-2026-6521**), and LZ77 decompression path (**CVE-2026-6533**), alongside crashes in BEEP (**CVE-2026-6538**) and other protocol handlers. GitLab issue reports show researchers and fuzzing jobs repeatedly triggering heap overflows, double-free conditions, NULL dereferences, and non-advancing-offset parser failures in components such as DCP-ETSI, H.245, MIH, eDonkey, and `sharkd`, underscoring that malformed captures can destabilize both the GUI and `tshark`. Wireshark said it was not aware of active exploitation at disclosure time and urged users to update to the fixed releases.
Aug 21, 2026