Wireshark Frame Metadissector Crash: Check Your Version Before Opening Captures
CVE-2026-96422 affects Wireshark’s Frame metadissector. Check affected versions, install the fix, and handle crash-triggering captures carefully.
Upgrade affected Wireshark installations before reopening a capture that crashes the analyzer. Wireshark’s September 23, 2026 advisory, wnpa-sec-2026-102 / CVE-2026-96422, describes a Frame protocol metadissector crash. It identifies two possible exposure paths: a malformed packet injected onto the wire, or opening a malformed packet trace file. The stated impact is a Wireshark crash—not a demonstrated compromise of the captured endpoints. See the official advisory.
Affected and fixed versions
The advisory lists these upstream release ranges:
| 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 |
Both the 4.6.9 release notes and the 4.4.19 release notes list this vulnerability as fixed. These are the advisory’s affected ranges; they should not be read as a safety guarantee for unlisted, older builds.
As of October 26, 2026, the official download page offers 4.6.9 as stable and 4.4.19 as old stable. Use that page for current packages rather than an installer attached to a troubleshooting message.
What “Frame metadissector” means
Wireshark’s Frame entry describes information about a captured packet, including arrival time, frame length, captured length, capture interface and comments. It is not a separate application protocol that you can identify simply by a TCP or UDP port. The Frame reference documents this metadata.
The practical distinction is between the traffic being analyzed and the analyzer processing it. A Wireshark process crash does not, by itself, establish that a server reset a connection, that the network dropped packets, or that someone deliberately attacked the workstation.
The linked issue report documents a TShark crash while building a full protocol tree from a pcapng file containing repeated packet comments. Command-line analysis workflows therefore deserve attention too; this is not solely a GUI troubleshooting concern.
The advisory says Wireshark is unaware of exploits for this issue. That statement is not a guarantee that every capture is safe.
Update and verify
- Check the installed executable without opening the suspect file. If Wireshark is on your command path, run:
sh
wireshark --version
The option is documented in the Wireshark manual. Check each installation you actually use, including portable copies and installations serving TShark automation.
-
Install a fixed stable release. For upstream packages, use 4.6.9, 4.4.19 or a later stable release. For distribution-managed packages, check the distribution’s security notice for CVE-2026-96422 or ask the distributor to confirm that your installed package contains the fix.
-
Close old processes and verify again. Confirm that the executable you launch now is the updated one before resuming analysis.
-
Keep suspect captures out of routine processing until the update is confirmed. Do not repeatedly reopen a crash-triggering trace in an affected build just to identify the failing packet.
A display filter is not a substitute for the update. Wireshark’s filtering guide explains that display filters only change which packets are shown; all packets remain in the capture file.
If the crash continues after updating
Record the exact version, operating system, whether the failure occurs during live analysis or file opening, and the error text. Treat a continuing crash as a separate diagnostic problem rather than automatically assigning it to this CVE.
Preserve the original capture privately. Inspect only traffic you own or are authorized to analyze, and do not publish third-party packet data. Before sharing diagnostics, redact payloads, tokens, addresses and identifiers. Even encrypted captures can expose sensitive metadata, as explained in what HTTPS hides—and leaves visible.