Wireshark’s 802.11 dissector crash: update before reopening the capture

Update before reopening a suspect wireless capture. Wireshark’s September 23, 2026 advisory, wnpa-sec-2026-109 / CVE-2026-96416, describes a crash in the IEEE 802.11 protocol dissector. The prescribed fix is Wireshark 4.6.9, 4.4.19 or later in the corresponding release branch. Official advisory

This is a failure in the analyzer processing Wi-Fi frames—not, by itself, evidence that the access point or client crashed.

Affected and fixed versions

Release branch	Affected versions	First fixed version
4.6	4.6.0–4.6.8	4.6.9
4.4	4.4.0–4.4.18	4.4.19

These ranges come from the Wireshark advisory. Use the official download page or your organization’s approved package channel to obtain a maintained release containing the fix. The first fixed versions are minimums for this issue, not a recommendation to stop updating.

For distribution-managed packages, check the vendor’s security notice if its version number remains below those minimums: a backported fix needs vendor confirmation.

What reaches the vulnerable code?

The advisory identifies two possible paths: a malformed packet arriving during live analysis, or a malformed saved trace opened by an analyst. It says Wireshark was unaware of exploits for the issue. That records the project’s knowledge when the advisory was published, not a guarantee about current exploitation. Advisory impact statement

The linked original bug report adds an important configuration condition: the reported crash requires 802.11 decryption enabled and at least one configured 802.11 key. It reports crashes in both Wireshark and TShark while processing Fast BSS Transition association or reassociation frames. This makes wireless-decryption profiles and automated TShark analysis relevant, not just the GUI. Original issue report

The packet representation matters, too. Capturing through a Wi-Fi interface does not necessarily produce raw 802.11 frames. Drivers often supply Ethernet-style packets instead; monitor-mode captures commonly expose the management frames and wireless headers needed for radio-layer analysis. Behavior depends on the platform, adapter and driver. Wireshark WLAN capture documentation

For choosing that capture point, see how to capture packets from a wireless client. A filename containing “Wi-Fi” is not enough to establish which headers the file contains.

A safe recovery workflow

1. Stop repeatedly opening the failing file on the affected installation. Preserve the original privately and record the application version, capture source and active profile. Note whether wireless decryption and keys were configured; do not include the keys in a public report.
2. Update every analyzer that processes the capture. Include workstation installations, command-line jobs and analysis containers. To check the TShark executable available in your shell, run:

sh tshark --version

This prints version information without opening the trace. TShark manual 3. Verify the installed fix before retrying. Close old analyzer processes, then reopen an authorized copy of the capture with the updated installation. If an update is not yet available, defer analysis rather than treating a changed display filter as protection. 4. If it still crashes, investigate it as an unresolved failure. Record the updated version, operating system, profile settings and crash output. A repeatable crash does not establish that this particular CVE caused it, or that someone deliberately supplied a malicious frame. Share only authorized, appropriately sanitized diagnostic material through an approved channel.

A display filter is not a security boundary. Wireshark’s documentation says display filters hide packets without removing them from the capture. Filtering the view to tcp, or excluding wlan, should therefore not be treated as a substitute for the update. Display-filter documentation

Keep the two questions separate: first, can the analyzer safely process the file? Then, what do the surviving packet observations establish about the network?