Wireshark 4.6.9: When the Tool You Trust to Read Traffic Has 19 Ways to Bite Back

Wireshark is the tool a lot of us reach for specifically because it feels safe: point it at traffic, read what's inside, nothing on the wire can touch you back, it's just bytes on a screen. Version 4.6.9, released September 23, 2026, is a useful reminder that this isn't quite true. Wireshark shipped 19 CVE-numbered fixes in this release, alongside several unnumbered remote-code-execution bugs reported through Trend Micro's Zero Day Initiative, and every one of them exists because something has to actually parse those bytes before you get to read them safely. That something is Wireshark's dissectors, and parsing untrusted input is exactly where security bugs like to live.

What actually shipped in 4.6.9

The fix count breaks down cleanly once you group it by what kind of bug it is rather than which protocol it's in. Most of the 19 CVEs are straightforward crashes: malformed traffic in the ZigBee ZCL, SCTP, SPDY, CSN.1, MBIM, RF4CE, X11, IEEE 802.11, and Catapult DCT2000 dissectors, plus the Sharkd utility, can be crafted to crash Wireshark outright. A smaller set are infinite loops rather than crashes, in the TTL and TIFF file parsers and in USB HID processing, which is its own kind of denial of service since Wireshark just hangs instead of failing cleanly. A couple are memory leaks, in the IEEE C37.118 Synchrophasor dissector and again in USB HID, and one, in the Microsoft Network Monitor capture parser, is described as an excessive loop that degrades performance rather than hanging outright.

None of that is exotic. Crash and hang bugs in file parsers are the most common class of security finding there is, and Wireshark's dissector count runs into the thousands, so 19 fixes in a single release is not itself alarming. What's worth separating out is the small number of bugs in this same release that go past crash-and-hang into actual code execution.

The two kinds of "code execution" in this release, and why they're different

Wireshark's own advisory for wnpa-sec-2026-106, CVE-2026-96419, describes a crash and possible code execution triggered by importing a specially crafted configuration profile. That's worth sitting with for a second: a Wireshark profile, the kind of file analysts export and hand off to a teammate or download from a shared repo of useful display-filter presets, is not something most people think of as executable content. This bug says it can be.

Separately, and not tracked under a CVE number yet, Wireshark's release notes credit Trend Micro's Zero Day Initiative with reporting an integer overflow in LBMC fragment reassembly and a numeric truncation error in LoRaWAN decryption, both described as remote code execution. Unlike the profile bug, these trigger from the capture data itself, meaning a malicious packet or a malicious capture file someone hands you could, in principle, do more than just crash your analyzer. ZDI-reported bugs commonly ship a release ahead of their CVE assignment, so don't read the missing CVE number as the bug being less real, it just hasn't been catalogued yet.

Between those two, the practical lesson is the same either way: Wireshark's attack surface isn't only "traffic on the network you're capturing." It's also every profile, every saved capture, every .pcapng file someone emails you for a second opinion. All of it gets parsed before you see it.

Every affected component in this release, at a glance

Why a "read-only" tool has an attack surface at all

I think about this the same way I thought about the nine packet captures I worked through for CCNA study: Wireshark's entire value is turning raw, hostile-by-default bytes into something a human can read safely. But turning bytes into something readable requires code that understands the format of those bytes well enough to parse them, and that code runs with the same permissions as whoever opened Wireshark. If the person crafting those bytes knows the parser well enough, they're not handing you data anymore, they're handing you input to a program, and every program that accepts untrusted input has to get every single parsing decision right or it doesn't.

This is precisely why a security tool being widely used doesn't make it exempt from this. Wireshark has one of the most heavily audited codebases in open-source networking software, specifically because thousands of people who understand protocol parsing use it daily and plenty of them go looking for exactly these bugs. Nineteen fixes in one release isn't a sign the project is careless, it's closer to a sign the review process is actually working, catching issues before they show up as something worse than a CVE number.

What to actually do about it

Upgrade. Wireshark 4.6.9 covers the 4.6 branch and 4.4.19 covers old-stable, released the same week and rolling up the same fixes, so whichever branch you're on has a release waiting. Beyond the version bump, two habits are worth picking up regardless of how urgent any single CVE here is. Treat a Wireshark configuration profile you didn't create yourself the same way you'd treat an email attachment: don't import one from an unfamiliar source just because it promises useful display filters. And if part of your job, lab work, or CCNA study involves opening capture files that came from somewhere other than your own traffic, run that analysis in a VM or a disposable environment rather than your daily driver, the same way you'd handle a suspicious executable rather than a trusted one.

None of this is a reason to distrust Wireshark specifically. It's a reason to remember that the tool sitting between you and hostile traffic is still software, parsing bytes it did not choose, and software that parses untrusted bytes is exactly the kind of software worth keeping current.

Frequently asked questions

How many vulnerabilities does Wireshark 4.6.9 fix?

Nineteen CVE-numbered issues, spanning protocol dissectors, capture file parsers, the Sharkd utility, and profile import. Wireshark also quietly fixed several additional code-execution bugs in the same release, reported through Trend Micro's Zero Day Initiative, that do not have CVE numbers assigned yet.

What is a Wireshark dissector, and why does it matter here?

A dissector is the code that reads a specific protocol's bytes off the wire and turns them into the readable fields you see in Wireshark's interface, one dissector for ZigBee, one for SCTP, one for X11, and so on. Every dissector is a small parser written to handle whatever bytes show up, and a parser handling attacker-controlled bytes is exactly the kind of code that tends to have crash and memory-safety bugs, which is what most of this release's 19 fixes are.

Can opening a malicious packet capture actually compromise my machine?

Some of the bugs in this release say yes. Two RCE-class issues, an LBMC fragment reassembly integer overflow and a LoRaWAN decryption numeric truncation bug, were reported as remote code execution triggered by crafted capture data, not just a crash. Wireshark's own dissectors run with whatever privileges the person running Wireshark has, so a capture file is not inert data the way it looks.

Should I upgrade from Wireshark 4.4 instead of 4.6?

Both branches got a security release the same week, 4.6.9 for the current stable line and 4.4.19 for the old-stable line, and both roll up the same set of fixes. Pick whichever branch you're already on and take that branch's release. Staying on an older point release in either branch leaves the same 19 CVEs open.

What is the most severe bug in this release?

CVE-2026-96419 stands out because it does not require opening a suspicious capture at all, it triggers from importing a specially crafted configuration profile, and Wireshark's own advisory describes the outcome as a crash or possible code execution. Profiles get shared between analysts and teams more casually than capture files do, which makes this one worth knowing about specifically.

What should I actually do about this release?

Upgrade to 4.6.9 or 4.4.19 depending on your branch, treat unsolicited capture files and shared configuration profiles the same way you'd treat an unsolicited attachment, and if you regularly open captures from outside sources, do it in a VM or sandboxed environment rather than on your main analysis workstation.