Wireshark TLS dissector crash opens door to code execution

TL;DR - Wireshark 4.6.0 through 4.6.4 contains a TLS dissector bug that crashes the application and could execute untrusted code. The trigger is a malformed TLS packet on the wire or a crafted .pcap file. Update to 4.6.5.

What happened

Wireshark is the de facto standard for packet capture analysis - if engineers are inspecting traffic, they're probably using it. Advisory wnpa-sec-2026-14 describes a vulnerability in the TLS dissector that can crash Wireshark and potentially execute untrusted code.

The attack paths are simple:

• Inject a malformed TLS packet onto a network segment where someone is capturing traffic.
• Convince someone to open a crafted capture file containing the malformed TLS records.

Dissector bugs in Wireshark follow a recurring pattern. The application sits exactly on the trust boundary: attacker-influenced bytes flow directly into a large native-code parser, often running on a privileged analyst workstation. That combination keeps these vulnerabilities high-impact when they appear.

Who is impacted

• Anyone running Wireshark 4.6.0 through 4.6.4.
• Highest-risk environments:
  • analysts and engineers who open capture files from external sources - vendors, customers, incident response partners
  • teams capturing traffic on hostile or untrusted networks where an attacker controls packet contents
  • shared analysis hosts and jump boxes where a crash or code execution could enable lateral movement

What to do now

• Upgrade Wireshark on all affected endpoints.

  "Upgrade to Wireshark 4.6.5 or later."

• Inventory every machine that has Wireshark installed: developer workstations, lab VMs, incident response toolkits, base images. Prioritise hosts where capture files arrive from outside your trust boundary.
• Until you can patch, treat third-party .pcap and .pcapng files as potentially hostile:
  • open them inside an isolated VM or sandbox first
  • avoid running Wireshark with elevated privileges on analysis hosts
• If analysts may have already opened suspicious capture files, look for unexplained Wireshark crashes and trace the provenance of those files - who provided them, through what channel, and when.