CVE-2026-76919 is a medium severity (5.3) flaw in Wireshark's ESS protocol dissector. A malformed packet or capture file could crash it. The project fixed it in 4.6.8 and 4.4.18 and says it is unaware of exploits. The issue report traces it to an uninitialized pointer.
What's affected
Wireshark's advisory wnpa-sec-2026-86, dated 12 August 2026, lists affected versions 4.6.0 to 4.6.7 and 4.4.0 to 4.4.17, and fixed versions 4.6.8 and 4.4.18. Impact is stated as a crash, and the project says it is unaware of any exploits.
Where sources differ. The record gives the 4.4 range as 4.4.0 to 4.4.18, and the advisory gives 4.4.0 to 4.4.17 with 4.4.18 as the fixed release. Use 4.4.18. The record scores it 5.3 Medium with a network vector and no user interaction, while the advisory says malformed content must be injected or a capture file read. The public issue describes unsafe handling that could lead to a dissector exception, a crash in diagnostic builds, or unsafe memory access depending on the stack value. We follow the advisory for impact and the record for the score.
How to check if you're exposed
Print the version of every Wireshark and TShark install, including copies on analyst laptops, jump hosts and build images:
wireshark -v
tshark -v
Affected: 4.6.0 to 4.6.7 and 4.4.0 to 4.4.17. Anything older than 4.4 is outside what the advisory lists, so check the project page for end of support. Also find automated jobs that run TShark on captures from outside, such as sandbox pipelines or packet inspection scripts, because those open untrusted files without a person in the loop.
What to do now
- Upgrade Wireshark to 4.6.8 or 4.4.18 or later, the versions the advisory names.
- Upgrade TShark and any bundled copies, such as those in tooling images.
- Until then, avoid opening capture files from untrusted sources and avoid live capture on untrusted networks with the vulnerable build.
- Review automation that runs TShark on files you did not create, and add the update there first.
- Record the version after the upgrade.
Why it matters
The public issue explains the mechanism: a malformed BER bit string in an ESS security category attribute can leave a pointer uninitialized, and the dissector then uses it in attribute flag handling. That is use of an uninitialized variable, and the record files it under CWE-457. The advisory itself keeps the description to a crash.
ESS shows up in CMS and S/MIME style content, so the exposure is mostly analysts who open captures with that kind of traffic. The risk is bounded, since a crash in an analysis tool is not a breach of the network it watches, but a tool that runs unattended on outside captures should still be updated. The record does not mark it as a CISA KEV entry.
Quick check
Which Wireshark versions are safe?
4.6.8 and 4.4.18 or later, according to the advisory.
Does it matter for TShark?
Yes, if the TShark build uses the same dissector code. Update it with Wireshark, and check any automated jobs that read outside captures.
Sources
Last reviewed: 18 October 2026.
