Security 11018 Published by

Wireshark shipped two coordinated security updates with version 4.6.9 for its current stable line and 4.4.19 for the older "old stable" branch. Together the two releases close at least 35 vulnerabilities across the protocol dissectors that power the tool, with 19 fixes in 4.6.9 and 16 in 4.4.19. Most bugs are local crashes that require opening a crafted capture file, but several can be triggered remotely and a handful carry RCE potential, including defects flagged by Trend Micro's Zero Day Initiative. The updates add no new features, so the guidance is to patch both installations while verifying the signed tarballs before install.



Wireshark ships two coordinated security updates, patching roughly 35 flaws

Both the current stable line and the older "old stable" branch get the same hardening. Some fixes can be triggered remotely. A few can execute code. Here's what matters.

Wireshark pushed two security updates on September 23, 2026, back to back. Version 4.6.9 targets the current stable line. Version 4.4.19 hits the older "old stable" branch. Together they close at least 35 vulnerabilities in the protocol parsers that form the core of the tool. There is no feature creep here. No new protocols. Just parsers that have to trust hostile data, patched so that hostile data breaks less often.

Wireshark

Why two version numbers

Wireshark runs two major version lines at the same time. The stable line gets full feature and bugfix updates. The old stable line keeps receiving security-only patches for a while. That is why one patch day produces two releases.

Current service lines are 4.6.x, 4.4.x, and a development line at 4.7.3. There is no 4.5 line. The project skipped it.

Keep in mind that the 4.6.9 and 4.4.19 lists overlap heavily, since the same fixes get cherry-picked onto both branches. The newer build closes three bugs the older branch never touches: ZigBee ZCL (wnpa-sec 2026-92), the TTL file parser (2026-94), and PEAK CAN TRC (2026-95). Those code paths simply do not exist in 4.4.x. So 4.4.19 lands 16 fixes and 4.6.9 lands 19.

Both were signed by Gerald Combs, the project's long-time lead, using GPG key id 0xE6FEAEEA.

The bugs themselves

Head here to the release notes for the technical detail, where each fix carries a wna-sec ID, a bug-tracker issue, a CVE, a root cause, and a CWE. The patterns repeat. Integer overflows. Out-of-bounds reads and writes. Uninitialized pointers. Missing bounds checks. Missing loop detection. It is a textbook catalog of parser mistakes, and the CWE spread (122, 126, 835, 401, 476) says as much.

Most of the fixes are local: you have to open a crafted file, and the payoff is usually a crash. Several can be hit remotely. A few can execute code.

Three high-risk, network-exploitable fixes all trace back to Feng Xue, whose "Security research assessment of Wireshark internals" keeps turning up the same classes of bugs. Those hit the SCTP dissector (2026-93), SPDY (2026-97), and CSN.1 (2026-99), each via a reassembly integer overflow that becomes a heap buffer overflow.

Then there is the profile-import bug (2026-106), described as a possible code execution. It is a follow-up to an earlier incomplete fix for CVE-2026-5656, and it quietly slipped through on Windows via an #ifndef _WIN32 guard. A reminder that security patches sometimes need a second pass.

The non-security bug list is where the RCE talk really lives. Wireshark flags several defects tied to Trend Micro's Zero Day Initiative advisories as RCE-capable. An LBMC fragment-reassembly integer overflow (ZDI-CAN-32846), a LoRaWAN decryption numeric truncation (ZDI-CAN-32851), and an SMB object-export integer overflow (ZDI-CAN-31676). A separate DICOM export bug wraps a uint32 length, allowing an undersized allocation and a heap overwrite.

For what it is worth, the attacker bar stays high for most entries. A crash on a local crafted file is annoying but not catastrophic. The AV:N and RCE entries are the reason to take this seriously. But an attacker still needs Wireshark or TShark to open a malicious file, or in remote cases to get the tool to dissect hostile traffic.

Who keeps finding these

A lot of these fixes come from a small, recurring roster. Feng Xue alone accounts for several of the high-rated entries. "Claude and Ada Logics" shows up across the USB HID, TIFF, X11, 802.11, and Catapult fixes. OpenSec Intelligence (Mayank Jangid) handles a cluster of crashers. Trend Micro's Zero Day Initiative, Aisle Research, and Daniel Birtwhistle round out the list.

If you follow the project, a day like this looks familiar. The release notes have quietly become a living ledger of who found what, and the contributor credits read like the same dedicated fuzzers year after year. That is not a random scatter of one-time reports. It reads like a structured, sustained program of poking dissectors with malformed data and seeing what breaks.

The tool was originally named Etherreal before Combs renamed it in the early days. It is fitting that the same kind of disciplined tinkering is what keeps a 28-year-old parser alive.

What to do

Since these are parser-hardening patches with no new features, the move is simple. Update. Both the stable (4.6.x) and old-stable (4.4.x) installs to the September 23 versions.

One wrinkle for Linux deployments: 4.6.9 now searches extcap binaries under libexec by default, so /usr/libexec/wireshark/extcap instead of /usr/lib64/wireshark/extcap. Third-party extcap packagers may need to move their files. You can still override with the WIRESHARK_EXTCAP_DIR variable.

Head here for the stable (4.6.9), old stable (4.4.19), and development (4.7.3) builds.