Wireshark profile import flaw: update before importing shared profiles

Update Wireshark before importing shared configuration profiles. Wireshark’s September 23, 2026 advisory for CVE-2026-96419 says a crafted profile could crash the application or execute arbitrary code. The fixes are 4.6.9 and 4.4.19, or later releases. The trigger described is convincing someone to import a malformed configuration profile—not simply observing traffic on a network. Wireshark security advisory

Which versions are affected?

Release branch	Affected versions	First fixed version
4.6	4.6.0–4.6.8	4.6.9
4.4	4.4.0–4.4.18	4.4.19

These ranges come from the official advisory. The 4.6.9 release notes also list this vulnerability among the fixes. Do not interpret an older, unlisted branch as a safe alternative; move to a maintained, patched release.

Why a profile is a security boundary

A configuration profile is not a packet capture. It stores analysis settings such as preferences, capture and display filters, coloring rules, disabled protocols and “Decode As” assignments. Wireshark supports importing profiles from ZIP archives and directory structures. A profile shared alongside a troubleshooting capture is therefore a separate input that deserves its own trust check. Configuration Profiles documentation

The report linked by the advisory describes a Windows ZIP-extraction path-containment failure: archive contents could be written outside the intended extraction directory and later loaded as code. The reporter also describes an import that displayed “No profiles found” despite having written a file.

That is a reported failure mode, not a reason to narrow the official affected-version ranges to one platform. It also means an unsuccessful-looking import is not reliable evidence that nothing happened. You do not need to import a shared profile just to inspect the accompanying capture; decline it and use your own analysis settings instead.

Update before resuming profile imports

If you suspect a malicious profile has already been imported, follow the incident guidance below rather than reopening Wireshark to check its version.

1. Check the installed application version. Open About Wireshark and record the version of the copy you actually use. Check other installations separately, including portable copies and analysis virtual machines.
2. Pause imports from unverified sources. Do not retry a suspicious archive on the vulnerable installation. If you only need someone’s filters or column layout, ask for a plain-text description and recreate the settings yourself.
3. Install a patched release. Use the official download page or your organization’s approved package source. For distribution-managed packages, verify that the vendor explicitly includes the CVE-2026-96419 fix rather than relying only on the upstream-looking version number.
4. Verify the version after updating. For an ordinary update with no suspected malicious import, reopen Wireshark and confirm the installed version before importing profiles again.

If you already imported a suspicious profile

Treat this as a possible endpoint-security incident, not merely a failed configuration change. Stop using that Wireshark installation and avoid relaunching it just to see whether the import worked: the linked report describes code loading on a subsequent launch.

Preserve the original archive, its source, the import time, the Wireshark version if known, and any error message for your security team. Avoid circulating the archive or associated captures casually; captures may contain sensitive traffic data.

Installing the fix is not the same as undoing a prior malicious import. Have your security team assess unexpected files and possible execution, and use a clean, patched analysis environment while the original host is reviewed. A crash alone does not establish code execution, but a “No profiles found” message does not rule it out either.