Wireshark 4.6.5 patches 43 vulnerabilities including 38 CVEs

Wireshark 4.6.5 fixes 43 vulnerabilities, including 38 CVEs, and lands alongside 35 bug fixes. The update matters because several of the flaws were in protocol dissectors, the code Wireshark uses to decode network traffic and display it in a human-readable way.

According to the SANS Internet Storm Center notice, the patched issues could be triggered by specially crafted network captures. In practical terms, that means a malicious or malformed packet capture file could cause Wireshark to misbehave when a user opens it, rather than requiring the attacker to be sitting on the same network in real time.

Wireshark is the most widely used open-source packet analyzer in enterprise IT, security operations, and incident response. Analysts use it to inspect traffic, troubleshoot connectivity problems, and study protocol behavior. Because it sits directly on top of untrusted network data, bugs in dissectors tend to get attention quickly, especially when they can be reached through a capture file.

A CVE, or Common Vulnerabilities and Exposures record, is a tracked security issue that vendors and researchers can reference consistently. Having 38 CVEs in one release does not automatically mean 38 different products are at risk, but it does indicate a broad patch set touching many parts of the application or many separate protocol parsers.

Protocol dissectors are a common source of security bugs in packet tools. They have to handle a huge variety of protocol fields, lengths, encodings, and edge cases, often from traffic that may be incomplete, corrupted, or intentionally crafted to break parsing logic. That makes memory corruption, crashes, and other parser errors a recurring concern in applications that inspect external data at deep levels.

The SANS ISC post points to Wireshark 4.6.5 as the maintenance release that addresses these issues. The release also includes 35 non-security bug fixes, which is typical for a point update of a mature tool used across many operating systems and workflows.

For security teams, the immediate issue is not just whether Wireshark can parse a packet correctly, but whether a capture file itself can become a delivery vehicle for an exploit. Packet captures are often exchanged between teams, stored in ticketing systems, attached to email, or pulled from third-party investigations, so they can come from outside the local trust boundary.

Wireshark’s role in daily operations makes that a real concern. Analysts often open captures from customers, remote sites, malware investigations, or vendor support cases, and those files may contain traffic that was never meant to be viewed by a parser with a bug.

The release also underscores a broader pattern in security tooling: the tools used to inspect hostile traffic are themselves exposed to hostile input. That is especially true for software that decodes dozens or hundreds of protocols, each with its own history of parsing edge cases and implementation mistakes.

Wireshark 4.6.5 is the current maintenance response to that problem, with fixes aimed at the protocol parsing layer and the surrounding application code that turns raw network data into readable analysis views.