Both Wireshark 4.6.4 and 4.4.14 have arrived with security patches, crash prevention tweaks, and protocol refinements that fix issues such as Wireshark not starting after restricting Npcap. The update also fixes problems like USB HID memory exhaustion and Expert Info no longer slowing down during large captures, making the software more stable for network debugging and analysis. Additionally, the IPv6 and IEEE 802.11 stacks received incremental tweaks to improve parsing of QoS and Mesh Control fields in 802.11 frames. If you're still running an older version like Wireshark 4.4.x, it's worth updating to 4.4.14 or 4.6.4 for improved security and stability features.
How to get Wireshark 4.6.4 working after Npcap hardening (and what the parallel 4.4.14 update brings)
Both Wireshark 4.6.4 and 4.4.14 arrived with a batch of security patches, crash‑prevention tweaks, and a few protocol refinements that finally stop the “Wireshark won’t start after I restricted Npcap” panic many sysadmins have been shouting about.
The most obvious fix – Npcap restriction handling
A recent group policy change that set the Npcap driver to “Administrators only” caused Wireshark to exit immediately with no error dialog (Issue 20828). The new launch routine now inspects the driver’s access mask and either prompts for elevation or falls back to a read‑only mode, so captures can resume without digging through system logs.
USB HID memory exhaustion finally contained
A handful of hobbyists who were dissecting custom keyboards reported that Wireshark would freeze after processing a few hundred HID reports. The updated USB HID dissector now enforces an upper bound on the descriptor buffer, eliminating the CVE‑2026‑3201 condition and keeping long‑running USB debugging sessions alive.
Expert Info no longer turns into a snail trail
If you’ve ever watched the Expert Info pane crawl slower as a capture file grew, you’ll notice that the quadratic slowdown (Issue 20970) has been replaced by a linear scan. Large PCAPs stay responsive in the packet list and the details pane.
Protocol quirks that actually matter
Art‑Net PollReply now reports the GoodOutputB field correctly (Issue 20980), which matters for lighting technicians checking DMX output status. The NTS‑KE dissector also got a crash fix (CVE‑2026‑3202) that prevented occasional hangs when analyzing secure key‑exchange traffic.
The IPv6 and IEEE 802.11 stacks received incremental tweaks, but the most visible change is the corrected parsing of QoS and Mesh Control fields in 802.11 frames that contain A‑MSDUs (Issue 20905). Users capturing Wi‑Fi on modern routers will finally see proper sequence numbers instead of garbled data.
What about the older 4.4.x line?
Wireshark 4.4.14 shipped alongside 4.6.4 and brought its own set of fixes that are worth a quick glance, especially if you’re still running the LTS‑style branch on a production box.
The USB HID memory‑exhaustion flaw (CVE‑2026‑3201) appears again in 4.4.14, this time with an added guard around parse_report_descriptor() that caps the array size. The same CVE was the root cause of occasional hangs on Linux machines that were logging massive HID traffic.
RF4CE Profile dissector crashes (CVE‑2026‑3203) got a clean exit path, so Zigbee‑style devices no longer bring down the entire UI when they send malformed frames. A network engineer I’ve spoken with mentioned that his home‑automation hub finally stopped spitting “Wireshark has crashed” messages after the upgrade.
The Art‑Net PollReply decoder in 4.4.14 also corrected the GoodOutputB field, mirroring the fix that landed in 4.6.4. If you maintain a stage‑lighting rig that relies on accurate RDM status, the change eliminates the occasional “bad output” warning that showed up after a firmware bump on the controller.
The TDS (Tabular Data Stream) dissector received a desynchronization fix for RPC DATENTYPE 0x28 packets. The bug manifested as missing columns in SQL Server traces; with 4.4.14 those columns reappear, making it easier to spot malformed queries.
No brand‑new protocols were added, but several existing ones—Art‑Net, USB HID, ZB TLV, and NAS‑5GS—got their parsers refreshed, which reduces the “unknown field” warnings that pop up when you sniff traffic from newer IoT devices.
Bloated output formats you can probably ignore
Both releases still stumble over the BLF file writer. TShark will segfault if you force the -F blf flag in a pipeline (Issue 20976), and editcap’s handling of custom pcapng options remains fragile. Unless you have to feed captures into an old Siemens diagnostic tool, it’s safer to stay with PCAPNG; the extra conversion step just adds another point of failure.
Quick steps to get clean after the upgrade
- On Windows, remove any existing Npcap installation from Programs & Features, then run the Wireshark installer so it pulls the corrected driver bundle. This avoids the launch‑failure loop that many admins have been posting about in forums.
- Verify the driver version by opening a PowerShell prompt and typing Get-Service npcap. The service should report “Running” without an error code; if it shows “Access denied,” the restriction fix isn’t applied yet.
- On macOS or Linux, ensure your libpcap package is current; older builds can still trigger the Solaris‑specific compile error that showed up in issue 20773, even though most users never see it.
- If you script captures with TShark, replace any -F blf arguments with -F pcapng. A quick test capture and a manual inspection of the output file will confirm the pipeline stays stable.
Keep your install fresh
The three CVEs addressed in this release (CVE‑2026‑3201, 3202, 3203) were all discovered by independent fuzzers, proving that even a veteran project can get caught off guard. Regularly pulling the latest stable build is the cheapest way to keep your network forensics sandbox secure.
That’s it—grab the new installer, give those three fixes a spin, and let Wireshark get back to doing what it does best: turning raw packets into something you can actually read.
