The Wireshark Foundation has released Wireshark 4.6.6, delivering an important round of security and stability updates that address a serious Dissector Crash vulnerability tied to the ROHC protocol parser, along with a separate global-buffer-overflow flaw affecting MACsec traffic analysis. The release focuses heavily on improving reliability for users handling untrusted packet captures and production monitoring environments.
At the center of the update is a security issue identified as wnpa-sec-2026-51, tracked internally as Issue 21243. The flaw involved Wireshark’s ROHC (Robust Header Compression) dissector, the component responsible for decoding compressed IP packet headers during network analysis.
According to the release notes, attackers could exploit the weakness by injecting a malformed packet into a live traffic capture or by supplying a crafted .pcap file. Successful exploitation could trigger a Dissector Crash, interrupting packet analysis sessions and potentially affecting operational monitoring systems.
The ROHC Vulnerability
The newly patched ROHC vulnerability emerged during fuzz testing campaigns conducted in May 2026. Researchers found that malformed packet injection could destabilize the protocol parser, exposing weaknesses in how Wireshark processed specific ROHC packet sequences. Because Wireshark is commonly used in enterprise monitoring, forensic investigations, and protocol debugging, the risk associated with a remotely triggered Dissector Crash raised concerns for security teams working with external or untrusted traffic captures.
In addition to the ROHC issue, developers also fixed a MACsec dissector global-buffer-overflow vulnerability tracked as Issue 21235. The flaw created a memory safety risk while parsing IEEE 802.1AE-secured traffic. The global-buffer-overflow condition was also identified through fuzz testing and represented another example of how malformed network traffic could affect protocol dissectors inside Wireshark.
Wireshark 4.6.6 Introduces Stability and Windows Compatibility Fixes
The Wireshark 4.6.6 release includes several other significant fixes aimed primarily at improving Windows compatibility and application stability. One major correction resolved a Windows crash affecting Visual Studio environments, documented under Work Item 24787. Developers also fixed uninitialized memory reads in both the pntoh16 and find_signature functions within the VeriWave (vwr) file reader, tracked under Issues 16460 and 16461.
Another high-profile issue involved compatibility problems introduced in Wireshark 4.6.5. Users reported that the software failed to run correctly on Windows 10 version 1809, Windows Server 2019, and certain Long-Term Servicing Channel (LTSC) editions. The regression, listed as Issue 21237, has now been resolved in the latest release.
The update also corrects an installation problem on Windows systems where optional features could be accidentally removed during upgrades if users did not explicitly preserve them. That issue was tracked as Issue 18925. Developers further addressed a packaging problem that caused Wireshark.exe version 4.6.5 to become nearly twice the size of version 4.6.4. The oversized executable issue, documented as Issue 21233, has now been fixed.
Two additional fuzz testing crashes discovered in May 2026 capture files, tracked as Issues 21240 and 21253, were also resolved as part of the release. These fixes collectively strengthen Wireshark’s resilience against malformed packet processing and parser instability.
Wireshark 4.6.6 now ships with Npcap 1.88, replacing the previously bundled Npcap 1.87 release. The updated packet capture library is intended to improve low-level packet capture reliability on Windows platforms. Although no entirely new protocols were introduced in this version, dissector support received updates for several technologies, including BACapp, MACsec, ROHC, Kafka, SIP, PFCP, and BPv7. Capture file handling improvements also extend to JSON and VeriWave formats.
On Unix-based systems, extcap binaries now default to the /usr/libexec/wireshark/extcap directory. While this behavior was originally introduced in Wireshark 4.6.0, the change has now been formally documented as part of the 4.6.6 release cycle.
