CVE-2026-76927 is a medium severity (4.7) flaw in Wireshark's H.245 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 describes a null pointer write.
What's affected
Wireshark's advisory wnpa-sec-2026-77, 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, while the advisory gives 4.4.0 to 4.4.17 and names 4.4.18 as fixed. Use 4.4.18. On severity, the record says 4.7 Medium. The public issue, filed by a security research team, rates its own finding at 6.5 Medium and describes a near null write that can terminate Wireshark or TShark. These are different scoring views of the same crash, so the point is the same: update.
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 issue report says the H.245 decoder clears an internal packet state pointer while it decodes a nested message, and a hook for one generic message type then writes through that null pointer. No call setup or earlier negotiation state is needed, which makes a single crafted control message enough. The record files it under CWE-476, null pointer dereference.
A null dereference is usually a denial of service, and the advisory frames it that way. The cost is lost work and a stalled capture, and in automated pipelines a stalled job. It still belongs in your patch queue because the fix is just a version bump. The record does not mark it as a CISA KEV entry.
Quick check
Is code execution possible?
The advisory describes a crash and says the project knows of no exploits. The issue report describes a near null write, which points to denial of service.
What is the fixed version?
4.6.8 for the 4.6 line and 4.4.18 for the 4.4 line, per the advisory.
Sources
Last reviewed: 18 October 2026.
