A Wireshark update every few weeks is not usually news I bother writing up. They look the same: a stack of dissector names nobody recognizes, a pile of crash fixes, and one or two functional changes tucked at the bottom. Most of the time I scroll past. 4.6.9 is the kind of release that pulls me back, because one of the 19 advisories shipped in this batch is exactly the sort of bug that should make any sysadmin pause and run the updater. If you have ever imported a profile from anyone other than yourself, read on before you open another capture file.
The single change that matters most
CVE-2026-96419 sits in the code path that loads shared Wireshark profiles. When you take a profile from another user and bring it onto your machine, the application can crash with the kind of fault pattern that hands control past the dissector and into deeper parts of the process. Once you are past that boundary, a crafted profile file can execute code under your user account.
That is the realistic scenario, not a contrived one. People trade profiles. Senior analysts hand junior ones their tuned filter sets and saved layouts. Vendors ship profile bundles with capture examples. Conference workshop materials include profile zips. Every one of those is a place a malicious profile could land in your downloads folder without raising suspicion. Wireshark’s profile import path was quietly treating every imported file as if you had vetted it yourself. After this patch, it does not.
If you do nothing else after reading this, update Wireshark. The rest of the changelog is interesting and worth a skim, but the door that closes here is the one you did not know was open.
Most of the other 18 advisories are the same shape as always
Wireshark advisories come in two flavors, and most of the 18 that sit alongside the headline fix are flavor one. A dissector, which is the part of the code that interprets a specific protocol’s bytes, misreads a malformed packet, walks off the end of a buffer, and the process dies. The data on disk is not modified because a capture file is read-only input. The session ends. You reopen the file and try again.
The dissectors and parsers that landed crash fixes this round:
- ZigBee ZCL, SCTP, SPDY, CSN.1, MBIM, X11, IEEE 802.11, RF4CE, and Catapult DCT2000
- TTL file parser and TIFF dissector both had infinite-loop bugs on bad input
- IEEE C37.118 Synchrophasor had a memory leak that added up over long captures
- USB HID could trigger both an infinite loop and a leak in the same session
- Sharkd, the daemon version that drives scripted analysis, got its own crash fix
The infinite-loop class is the one that bites automated pipelines. A capture file that hangs the parser also hangs whatever script was feeding it. If you batch-process pcap archives overnight, the right move is to update and then rerun the queue against fresh output.
Quiet fixes that will save more time than the CVE list
Skip the headlines for a moment. Several non-security fixes in this release will probably save more analyst hours than the profile import flaw, because the bugs they close are exactly what you fight for an afternoon before giving up and trying a different approach.
Bluetooth AVCTP reassembly had an integer overflow that would mangle packets while you were looking at audio streams. SMB object export had the same family of bug, which matters if you routinely pull SMB captures off Windows hosts. ETL parsing through the etwdump extcap had a stack buffer overflow, and stack overflows in parsing code are what quietly turns a stable analyzer into a flaky one. DICOM, the medical imaging protocol, had export bugs that would have derailed anyone debugging a hospital network.
From the rest of the functional changes:
- NULL-pointer dereference in PKCS12 handling
- Out-of-bounds read in DFVM
- F1AP decode glitches, which matter for 5G core work
- JA4 fingerprint math was ignoring the GREASE placeholder convention, so every JA4 fingerprint looked wrong until you knew to strip those bytes
- LoRaWAN decryption edge cases
That JA4 fix is small but worth noting if you use the fingerprint scheme. JA4 is a newer traffic fingerprinting convention, and GREASE bytes are placeholders clients send to test TLS compatibility. Tools that ignore them produce fingerprints that look strange. The fix handles them correctly.
One Linux detail that will not show up in the security advisory
Here is the part that will quietly break installations until someone notices. Since 4.6.0, Wireshark has looked for extcap helpers under libexec by default on Linux and the BSDs. That means /usr/libexec/wireshark/extcap is where the GUI expects to find capture helpers, not wherever your package maintainer used to drop them.
In a clean install, the path change is invisible. The moment you have a custom extcap script in a non-standard location, or you depend on a third-party package that has not been updated to match, the capture helper stops showing up in the menu. No warning, no error, just a missing entry.
Three things to check after you update:
- If you maintain third-party Wireshark tools, confirm they install to the new path
- If you keep personal extcap scripts, symlink them into
/usr/libexec/wireshark/extcap - If your distro split the package, confirm the extcap sub-package is installed and not just the main one
This is why I always read the full release notes. The security fix gets you off the older build. The path change is what costs you an evening if you do not notice it.
How to install the update
Pick the path you normally use. Package manager installs pick up 4.6.9 the next time you refresh; source builds pull the new tarball and replace the install; the official website ships the build for the platforms that matter. Whichever route, this is the kind of update that does not require a reboot or a service restart, just a relaunch of the application.
Trade-offs
Most of this batch is housekeeping, and that is a fair signal. Wireshark is healthy and well-maintained. The single exception is the profile import flaw, which is the kind of bug a project is glad to have caught before anyone weaponized it. After you install 4.6.9, be slightly more careful about where you pull shared profiles from for a couple of weeks while downstream packages catch up. If you maintain a fleet of analysis workstations, the libexec path change is the operational footnote worth emailing the team about, since nothing breaks loudly when it goes wrong. For everyone else running Wireshark on a single workstation, the urgency is mostly about the profile import flaw; the rest of the batch is the kind of background maintenance that pays off the next time a weird capture file lands in your inbox.
Bottom line
Update Wireshark to 4.6.9 today. The profile import flaw is real, the fix is small, and the update does not deserve to wait until your next maintenance window. If you depend on custom extcap scripts or third-party tools that wrap Wireshark’s capture path, check that those still resolve after the update, and add a symlink if they do not. Beyond those two checks, this changelog reads exactly as you want a healthy project’s release notes to read: small, careful fixes that close real doors without opening new ones.