Wireshark 4.6.8 Patches 28 Vulnerabilities and 25 Bugs: What SOC and IR Teams Should Do
Wireshark 4.6.8 lands with fixes for 28 vulnerabilities and 25 bugs. Every one of the 28 is a dissector or file-parser crash, not remote code execution, but because analysts open untrusted captures on their own machines, patching and sandboxing both matter.
Wireshark 4.6.8 shipped on August 16, 2026, and the release fixes 28 vulnerabilities and 25 bugs. That count matters more than usual for one reason: analysts point Wireshark at capture files that came from somewhere hostile, so a flaw in the code that parses those files is a flaw sitting on the analyst's own workstation.
The SANS Internet Storm Center flagged the release the same day, and the official 4.6.8 release notes list every advisory. Here is the load-bearing detail for anyone triaging this: all 28 of the newly disclosed vulnerabilities, tracked as wnpa-sec-2026-64 through wnpa-sec-2026-91, are dissector or file-parser crashes rather than remote code execution. Nine of them sit in file parsers, the exact code path that runs the moment an analyst opens a saved capture.
What Actually Broke
The crashing code spans both live-protocol dissectors and capture-file readers. On the dissector side, the fixes cover UMTS FP, RDP, the Bluetooth Attribute Protocol, C12.22, CMS, H.245, Kerberos, SSH, ESS, X.509IF, RRC, and the Bluetooth HFP, BR/EDR FHS, and AVRCP profiles. On the file-parser side, they cover the TTX Logger, BUSMASTER, Tektronix K12xx, ERF, Catapult DCT2000, 3GPP phone-log, Ixia IxVeriWave, Vector Informatik BLF, pcapng, and Gammu DCT3 formats.
One advisory, wnpa-sec-2026-87 in the X.509IF dissector, still carries a pending CVE identifier in the release notes rather than an assigned number, so expect that reference to firm up over the coming days. None of the 28 is described as enabling code execution, and none is listed as actively exploited. That is a real contrast with earlier releases in the 4.6 line, where a handful of advisories carried the vendor's "crash and possible code execution" wording. This batch is a crash and denial-of-service set, full stop.
Wireshark ships security-driven point releases on a roughly monthly cadence, and 4.6.8 continues the 4.6 branch that has absorbed a heavy run of dissector fixes through 2026. The practical takeaway is not the individual advisory numbers, which few teams will read line by line, but the shape of them: a wide spread of protocol and file-format parsers, each reachable by feeding Wireshark a specially built input.
Why a Crash Bug Still Matters to a Defender
It is tempting to file a stack of crash bugs under "low priority." Resist that for Wireshark specifically. The tool's whole job is to open captures an analyst does not trust: malware traffic pulled from a sandbox, a pcap handed over during an incident, a file attached to a threat-intel report. A crafted packet or capture that reliably crashes the dissection engine costs an analyst the session and any unsaved annotations, and a file that crashes on every open can stall an investigation at the worst possible moment. Memory-safety bugs that a vendor rates as crashes today also have a habit of being re-rated once someone looks harder at them.
Consider the delivery path, without getting into specifics. An analyst rarely chooses the captures they open. A capture arrives as evidence, gets pulled from a detonation sandbox, or lands in a shared case folder, and the person opening it assumes the risk lives in the traffic, not in the tool. That assumption is exactly what a dissector or file-parser bug turns against them. The fix that Wireshark's maintainers shipped closes these specific crash paths, but the structural exposure, one trusted tool reading untrusted input, does not go away between releases.
The 25 non-security bug fixes reinforce the "just update" case. They include a stack buffer overflow in the K12/RF5 writer, a stack over-read in the Sniffer error path, and an out-of-bounds read in androiddump, plus corrected 5G NAS decoding and two long-standing Windows annoyances: a Capture File Properties hang that has been around since 4.6.6, and a segfault when toggling the "Analyze TCP sequence numbers" preference.
The Fix Is Boring, Which Is the Point
The move is not complicated: update Wireshark to 4.6.8 everywhere an analyst runs it, and handle untrusted captures in an isolated environment so a parser bug fails inside a sandbox instead of on a production workstation. Analysts can confirm the running build under Help then About Wireshark, and teams that manage endpoints centrally can push 4.6.8 the same way they handle other open-source tooling. We walked through the same patch-and-contain discipline when Metasploit shipped its latest module batch and in our rundown of Microsoft's 421-CVE August Patch Tuesday.
My read:
This is a patch-and-move release, not a fire drill. The absence of any code-execution or in-the-wild flag means you do not need to pull analysts off other work tonight. Wireshark's threat model still earns it a fast lane, because it is one of the few tools your team deliberately aims at hostile input. Roll 4.6.8 to every analyst image this week, and if you are not already opening unknown pcaps inside a VM or container, treat that habit as the more durable fix. The next batch of dissector crashes is a question of when, not if.
