Wireshark fixed 18 vulnerabilities in one release and credits the volume to AI-assisted reports

The project itself says AI-assisted reporting changed the release

The Wireshark Foundation released versions 4.6.9 and 4.4.19 on 23 September 2026. Its announcement says both releases fix many vulnerabilities and attributes the volume to a recent trend in AI-assisted vulnerability reports.

The 4.6.9 release notes name 18 security advisories, numbered wnpa-sec-2026-92 through wnpa-sec-2026-109. That is a useful, falsifiable statement about output: AI-assisted work contributed to a release with an unusually large list. It is not evidence that all 18 findings have equal severity, that AI found them without human work or that attackers are using them.

Wireshark is unusually exposed to malformed input by design. It opens untrusted capture files and decodes live traffic from hundreds of protocols. A parser defect can be reached when an analyst opens a crafted trace, and some dissector defects can be reached by injecting a malformed packet onto a network the analyst is monitoring.

Twelve crashes dominate the list; resource exhaustion is the next pattern

Classification of the 18 advisories in the 4.6.9 release notes

Class	Count	Examples
Crash	12	ZigBee ZCL, SCTP, PEAK CAN TRC, SPDY, CSN.1, MBIM, Sharkd, frame metadissector, RF4CE, Toshiba, X11, IEEE 802.11
Infinite or large loop	3	TTL parser, Microsoft Network Monitor parser, TIFF dissector
Memory leak	1	IEEE C37.118 Synchrophasor dissector
Infinite loop plus memory leak	1	USB HID dissector
Crash and possible code execution	1	Profile import

The table uses the project's own short descriptions. It does not assign a severity that the release notes do not provide. A crash can still be operationally serious on a monitoring workstation, and an infinite loop can consume CPU and interrupt analysis. Neither should be described as code execution without evidence.

The release also lists non-advisory bug fixes with security implications, including heap overwrite, out-of-bounds read and two Zero Day Initiative entries described as remote code execution vulnerabilities. Those entries are important, but they are separate from the count of 18 named Wireshark security advisories. Combining both lists without explaining the boundary would inflate one number with another.

A packet analyser has two main input boundaries: the wire and the file

Several individual advisories explain the realistic reachability. The TIFF infinite-loop advisory says an attacker may be able to consume CPU by injecting a malformed packet onto the wire or persuading a user to open a malformed capture file. The IEEE 802.11 advisory uses the same two routes for a crash. Both say the project is unaware of exploits.

That produces different risk for different users. A desktop analyst who opens captures from customers, malware sandboxes or public samples processes files from outside the trust boundary. A sensor decoding live traffic may process attacker-controlled packets automatically. A machine on which Wireshark is installed but never used does not share the same immediate exposure.

The correct inventory question is therefore not only "do we have Wireshark?" It is "which version parses whose traffic and whose capture files?"

Exposure depends on how Wireshark receives input

Use case	Attacker-controlled input	Priority question
Analyst opens an external capture	The capture file	Can the workstation be isolated and updated before analysis?
Live capture on a monitored network	Packets reaching the capture interface	Can a remote sender reach an affected dissector?
Automated Sharkd or processing workflow	Uploaded or collected captures	Does the service parse files without user review?
Installed but not used	No current parsing path	Can the package still be updated during normal maintenance?

AI can increase discovery throughput and report-cleaning work at the same time

Wireshark's public reporting guidance asks people who use AI tools to find or draft a bug report to disclose that use and personally verify the steps and details before submitting. That is a small but important quality control. A model can produce candidate inputs, explain a sanitizer trace or draft a report. The project still needs a reproducible test, a correct affected range, a fix and a review that the fix does not break protocol decoding.

The April, July, August and September release notes show that this is not a one-off burst. Wireshark has repeatedly referred to AI-assisted vulnerability reports. The maintenance effect is visible: more parser paths are being exercised and more fixes are reaching supported branches.

The other effect is triage pressure. If AI reduces the cost of generating malformed inputs and reports, maintainers must separate duplicates, false positives, unreachable conditions and genuine security boundaries faster. Projects that accept AI-assisted reports need submission rules, reproducibility requirements and a way to credit both tools and human researchers without confusing tool output with validation.

Updating is simpler than ranking eighteen parser defects from scratch

The fixed versions are 4.6.9 and 4.4.19 for the supported branches named in the announcement. Teams should update the package that actually runs, including portable analyst images, forensic workstations, training environments, Sharkd services and base images used to create disposable analysis systems.

Where an update must wait, isolate the analysis environment, avoid opening untrusted captures on a privileged workstation and restrict automated upload paths. Those measures reduce reachability but should not become a permanent substitute for the release.

Key facts