Wireshark USB HID Infinite Loop: Affected Versions and Fix

Update to Wireshark 4.6.9, 4.4.19, or a later fixed release before reopening a suspect USB capture. Wireshark’s September 23, 2026 advisory, wnpa-sec-2026-103 / CVE-2026-96421, describes an infinite loop and memory leak in the USB HID protocol dissector. Malformed input may make the analyzer consume excessive CPU resources. Official advisory

This is a failure in the software interpreting the capture—not evidence that a USB device or network connection is itself stuck in a loop.

Which versions need updating?

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 security advisory. The 4.6.9 release notes also list this vulnerability among the fixes. Do not interpret the table as a recommendation to use an older, unlisted branch.

Obtain an updated package through the official Wireshark download page or your organization’s approved software channel. If a distribution supplies a backported fix without changing the upstream version number, confirm coverage for this CVE in its package security notice.

What causes the loop?

USB HID means USB Human Interface Device. In this issue, the dissector parses a HID report descriptor reconstructed from a USB control-transfer response. That descriptor tells the analyzer how to interpret the device’s reports.

The original issue report describes a usage-range expansion loop whose unsigned counter can wrap around rather than reach its exit condition. The loop keeps appending entries, so decoding can both spin and keep allocating memory.

The report describes the trigger as a malformed HID report descriptor carried in a usbmon or USBPcap capture, with no non-default settings required. It demonstrates the failure in TShark and describes its impact on Wireshark. Switching to an affected TShark build is therefore not a safe substitute for the GUI. These are the reporter’s findings, not a guarantee that every affected installation will fail identically. Issue 21566

The advisory identifies malformed live input and malformed trace files as possible trigger paths. Disconnecting from a network does not remove the file-opening risk. Its stated impact is excessive CPU consumption, alongside the described memory leak; it does not claim code execution. Official advisory

Recover without repeatedly triggering the failure

1. Stop the stalled analyzer. If it is unresponsive, terminate that process through your operating system’s process manager. Do not repeatedly reopen the same file in the affected build.
2. Keep the original capture restricted. Preserve it for authorized troubleshooting, but do not upload it publicly. Share it only with authorized recipients through an approved restricted channel, and warn them about the suspected trigger.
3. Update the tools you actually run. Include TShark installations used by scripts or automated analysis, not just the desktop application.
4. Verify the installed version after updating. For TShark, run tshark --version from the same environment your analysis job uses; the option is documented in the TShark manual.
5. Resume with an authorized copy on the fixed build. Monitor CPU use, memory use and whether decoding completes. If the hang persists, record the exact build, capture source and failure point for a restricted bug report. Redact payloads and identifiers before sharing any diagnostic output.

A hang alone does not identify this CVE. Treat a reproducible stall while decoding a USB HID capture on an affected version as a reason to update first—not as proof of malicious input or a faulty USB device.