Wireshark sharkd crash: check the backend version, then update

The Wireshark sharkd utility crash tracked as CVE-2026-95388 affects Wireshark 4.6.0–4.6.8 and 4.4.0–4.4.18. Wireshark recommends upgrading to 4.6.9, 4.4.19 or later, according to its September 23, 2026 security advisory.

If an application uses sharkd behind the scenes, check that backend—not just the Wireshark desktop version. Updating one installation does not establish that a separate service or container has been updated.

Affected and fixed versions

Release branch	Versions listed as affected	First fixed version
4.6	4.6.0 through 4.6.8	4.6.9
4.4	4.4.0 through 4.4.18	4.4.19

These ranges come from wnpa-sec-2026-101. Both the 4.6.9 release notes and the 4.4.19 release notes also list this issue among the vulnerabilities fixed.

Treat those versions as the minimum fixes for this advisory, not as a reason to select an old release. Use an appropriate current release from the official download page, or your operating system’s maintained packages. For packages with backported fixes, check the distributor’s security notice rather than relying on the upstream version number alone.

What sharkd does—and what this advisory establishes

Sharkd exposes Wireshark’s packet-dissection and analysis capabilities through a programmatic JSON interface. Applications can use it to load capture files, inspect protocol trees and apply display filters. It can run through standard input/output or as a socket-based daemon, as described in the Wireshark sharkd documentation.

The advisory identifies a possible sharkd crash. It does not establish credential theft, traffic interception or code execution. Its statement that Wireshark was unaware of exploits describes the advisory’s assessment; it is not a guarantee that untrusted input is safe.

A failed analysis worker is also not evidence of a network outage. First distinguish the process handling the capture from the endpoints whose traffic the capture records.

Update the backend and verify recovery

Pause automatic retries for the job that crashed while you check and update the deployment.

1. Identify the executable actually used. Inspect the service configuration, application launch command or container image. Record the executable path and package or build identifier. Do not assume your interactive shell finds the same binary as the service.

2. Check its version. The documented sharkd options include -v and --version:

sh sharkd --version

Run the check against the executable identified above, within the relevant deployment environment. If an older build does not recognize the option, inspect its help output and package/build records. The sharkd documentation describes the extended option set.

3. Replace the affected deployment. Update its package, rebuild from a fixed release, or replace the container image as appropriate. Restart the daemon and its workers so analysis uses the updated installation. Repeat the version check in that deployment and confirm that its launch configuration points to the updated executable.

4. Test with a small, authorized control capture. Confirm that the application can load it and complete the analysis operation you normally use. This checks basic integration; it does not prove that every capture or operation is safe.

5. Handle the failing input separately. Preserve a restricted-access copy of the capture and relevant logs. If further investigation is necessary, use an isolated, patched analysis environment rather than repeatedly submitting it to a production worker.

If sharkd still exits after the update

Record the deployed version, failing operation, exit status, stderr and application logs. Note whether the failure occurs during loading, frame inspection or another operation. A version in the affected range justifies updating; it does not, by itself, identify the cause of a particular crash.

For a bug report, redact sensitive paths, addresses, identifiers and any payloads or secrets from logs. Do not publish third-party captures, payloads, tokens or secrets. Share packet data only with authorization and through an appropriate restricted channel.

If the crashing process is the desktop analyzer rather than sharkd, investigate that distinction instead of assuming this CVE applies. The separate Frame metadissector crash guide covers another Wireshark crash advisory.