Wireshark, the protocol analyzer trusted by network engineers worldwide, has released version 4.6.8 to address 28 security vulnerabilities — nine of which require nothing more than a user opening a crafted file to detonate. The release is a reminder that the tools we use to inspect danger can themselves become the surface of attack, and that the quiet act of reading a file is never truly passive. Those who depend on Wireshark to understand their networks should update without delay.
Wireshark 4.6.8 patches 28 security bugs, nine exploitable via malicious files
A malicious file looks like any other file. The attacker never needs network access.
Mark
Why does opening a file matter more than network traffic? Isn't Wireshark designed to look at packets on the wire?
Mimi
Wireshark does both. It captures live traffic, but it also opens saved files—pcap files, mostly. Those files are portable. You email them to colleagues, share them in tickets, store them in archives. A malicious file looks like any other file. The attacker never needs network access to you.
Mark
So someone could send me a .pcap file that crashes Wireshark just by being opened?
Mimi
Exactly. Nine of these vulnerabilities do that. The file parsers run before any dissection happens, before you even see the packet list. The file itself is the attack surface.
Mark
What about the 5G decoding errors? Those didn't crash anything.
Mimi
Right. They just showed you wrong numbers. A UE security capability field, a Registration wait range—these are things a mobile engineer needs to trust. If they're wrong, you don't know it. That's harder to spot than a crash.
Mark
Why did it take eight releases to document the extcap path change?
Mimi
It happened in 4.6.0. Maybe it wasn't considered urgent enough to highlight until third-party developers started hitting the problem. Now it's in the notes so distributions know they need to repackage their extcaps.
Mark
Should I update immediately?
Mimi
Yes. The file parser vulnerabilities alone make this essential. And if you maintain any extcaps, check whether they need adjusting for the new path.
Der Puls
- Nine vulnerabilities in Wireshark's file parsers can be triggered simply by opening a malicious capture file — no network access, no elaborate setup, just a file handed to the wrong person.
- The damage extends deeper than the advisory count suggests: undocumented memory-safety bugs including stack overflows, out-of-bounds reads, and stack exhaustion were fixed without ever receiving formal vulnerability identifiers.
- Nineteen additional vulnerabilities scatter across protocol dissectors — RDP, SSH, Kerberos, Bluetooth, and others — plus the reassembly engine and sharkd daemon, widening exposure to scripted and automated workflows.
- Silent misdecoding of eight 5G fields means engineers may have been reading false values for UE security capabilities and other critical parameters without any crash or warning to prompt suspicion.
- Users must update immediately, and those relying on third-party extcap tools should verify binary paths, as a directory change introduced eight releases ago is only now being formally documented.
Wireshark, the protocol analyzer trusted by network engineers worldwide, has released version 4.6.8 to address 28 security vulnerabilities — nine of which require nothing more than a user opening a crafted file to detonate. The release is a reminder that the tools we use to inspect danger can themselves become the surface of attack, and that the quiet act of reading a file is never truly passive. Those who depend on Wireshark to understand their networks should update without delay.
Wireshark released version 4.6.8 this week, patching 28 security vulnerabilities — nine of them requiring no network access whatsoever. These nine live in the file parsers, the code that reads saved packet captures from disk before any analysis begins. Affected formats include pcapng, Endace ERF, Tektronix K12xx, BUSMASTER, Catapult DCT2000, and several others. An attacker's method is simple: craft a malicious capture file and send it to a target. Opening it is enough.
The remaining 19 vulnerabilities span the dissector layer, where raw bytes are transformed into the labeled fields engineers read in Wireshark's interface. Crashes were fixed in RDP, SSH, Kerberos, H.245, and multiple Bluetooth protocols, among others. The reassembly engine — a component every dissector depends on — also received a fix, as did sharkd, the daemon version of Wireshark used in scripted environments.
The advisory count still understates the release. Several memory-safety issues were corrected without formal vulnerability identifiers: a stack buffer overflow in the K12/RF5 writer, stack over-reads, out-of-bounds reads in androiddump and the BLF writer, and stack exhaustion from deeply nested JSON and recursive DLMS/COSEM parsing. Anyone tracking exposure by counting advisories alone is undercounting.
Separately, Wireshark corrected the decoding of eight 5G fields across NAS and 5GSM protocols. No crashes accompanied these errors — the screen simply showed wrong values, a subtler failure that offers no obvious signal to the engineer reading it.
The release also formally documents a path change for extcap binaries on Unix-like systems that has been in effect since version 4.6.0. Third-party extcap tools may need repackaging, though an environment variable override is available. Windows users additionally receive fixes for a long-standing dialog hang and a segfault tied to TCP sequence number preferences. With the prior release carrying 12 advisories and this one reaching 28, the jump reflects both genuine exposure and the intensity of the project's own fuzzing efforts. Update immediately.
Wireshark, the widely used protocol analyzer that sits on countless network engineer desks, released version 4.6.8 this week with patches for 28 security vulnerabilities. Nine of them are particularly dangerous because they don't require an attacker to touch your network at all. They activate the moment you open a malicious capture file.
Those nine vulnerabilities live in the file parsers—the code that reads saved packet captures off disk before any analysis begins. The affected formats span a broad range of capture types: pcapng, Endace ERF, Tektronix K12xx, BUSMASTER, Catapult DCT2000, Gammu DCT3, 3GPP phone logs, TTX Logger, and on Windows systems, Ixia IxVeriWave and Vector Informatik BLF. An attacker's path is straightforward: craft a malicious capture file and send it to someone. If they open it, the vulnerability fires. No network sniffing required, no elaborate setup. Just a file.
The remaining 19 vulnerabilities scatter across the dissector layer—the per-protocol code that transforms raw bytes into the labeled fields you see in Wireshark's packet detail pane. This release fixes crashes in RDP, SSH, Kerberos, H.245, ESS, X.509IF, RRC, and UMTS FP. Bluetooth gets four separate fixes covering ATT, HFP, BR/EDR FHS, and AVRCP. CMS and C12.22 each get two advisories. One more vulnerability sits in the reassembly engine, the component every dissector depends on to stitch fragmented data back together. Two additional crashes affect sharkd, the daemon version of Wireshark, meaning anything scripted on top of that utility faces the same exposure.
But the advisory count doesn't tell the whole story. The release notes list memory-safety fixes that never received formal vulnerability identifiers: a stack buffer overflow in the K12/RF5 writer, a stack over-read in the Sniffer REC_HEADER2 error path, an out-of-bounds read in androiddump triggered by a signed btsnoop length field, an out-of-bounds read in the BLF writer when processing truncated VLAN-tagged frames, and stack exhaustion from deeply nested NetLog JSON and from recursion in the DLMS/COSEM compact-array parser. If you're tracking exposure by counting advisories, you're undercounting this release.
Separate from the crash fixes, Wireshark corrected the decoding of eight 5G fields in NAS and 5GSM protocols. The S-NSSAI location validity information, NSAG information, UE security capability, Registration wait range, and Extended CAG information elements were all being misdecoded, along with the SOR transparent container, its SOR-CMCI field, and the service level AA container. Nothing crashed. The screen simply displayed wrong values—a harder failure to catch because an engineer reading a UE security capability field has no reason to suspect the numbers are false.
The release also surfaces a change that took effect eight point releases ago but is now documented for the first time. On Unix-like systems, Wireshark moved where it looks for extcap binaries from paths like /usr/lib64/wireshark/extcap to /usr/libexec/wireshark/extcap. Third-party extcaps may need repackaging to follow the new location, though the WIRESHARK_EXTCAP_DIR environment variable can override it. Distributions without a libexec directory, such as Alpine Linux, continue using the old path. Windows users get two smaller fixes: the Capture File Properties dialog, which has been hanging the application since version 4.6.6, and a segfault that occurred when toggling the TCP preference to analyze sequence numbers.
The prior release, 4.6.7, carried 12 advisories. Several of this release's fixes came from Wireshark's own fuzzing efforts, meaning the jump in vulnerability count reflects both genuine exposure and the project's testing intensity. Users should update immediately; the nine file parser vulnerabilities alone make this a priority.
Bemerkenswerte Zitate
An attacker never has to touch your network for these. They only have to get you the file.— Wireshark 4.6.8 release notes
Möchten Sie die ganze Geschichte?
Das Original lesen bei helpnetsecurity.com ↗
Media & Entertainment