CVE-2023-37679

What it actually does

This vulnerability affects the Wireshark package on Alpine Linux v3.5 before 2.2.14-r0. With the limited public description provided, the safest product-wide assessment is that the flaw is in Wireshark’s handling of network capture data or protocol parsing: a crafted packet stream or capture file can trigger unsafe behavior in the Wireshark/tshark analysis process, most commonly process crash/denial of service and, depending on the underlying parser condition, potential memory corruption within the privileges of the parsing process. Because Wireshark is often used to inspect untrusted traffic and shared packet captures, exploitation can occur through files or traffic that appear operationally legitimate.

Why it matters to the business

Organizations using vulnerable Wireshark builds can have packet-analysis workstations, automated tshark jobs, or forensic workflows disrupted or potentially compromised when analysts inspect malicious captures or when sensors parse hostile traffic. The risk is elevated because the exploit maturity is listed as weaponized and the EPSS score is extremely high, indicating broad exploit interest or likelihood even though the issue is not currently listed in CISA KEV. Systems that run Wireshark with elevated privileges, ingest captures from external parties, or automate analysis in CI, malware labs, SOC pipelines, or network monitoring environments face the greatest operational risk.

How an attack unfolds

An attacker prepares a malicious packet sequence or capture file that targets the vulnerable Wireshark parsing logic. The attacker then gets the victim organization to process that data, either by sending a crafted pcap/pcapng file to an analyst, placing it in a case bundle, exposing a sensor to crafted network traffic, or causing an automated tshark/Wireshark pipeline to ingest it. When the vulnerable Wireshark version parses the crafted content, the affected process may crash and interrupt analysis; if the flaw is memory-corruption-capable, exploitation could potentially execute attacker-controlled code in the context of the user or service running Wireshark. Post-exploitation activity, if achieved, would likely focus on the analyst workstation or analysis container rather than the originally captured network target.

How to fix it

Upgrade the Alpine Linux v3.5 Wireshark package to the fixed version 2.2.14-r0 or later. Where possible, move off the end-of-life Alpine v3.5 baseline entirely and use a supported Alpine release with currently maintained Wireshark packages. Until upgraded, avoid opening packet captures from untrusted sources on vulnerable systems; process suspicious captures only in disposable, isolated sandboxes; run Wireshark/tshark as a non-root user; disable unnecessary protocol dissectors where feasible; and restrict automated ingestion of externally supplied pcap/pcapng files.

How to confirm the fix worked

Confirm package remediation by checking the installed package version and verifying Wireshark is at 2.2.14-r0 or later on Alpine v3.5. For Alpine systems, use package inventory or `apk info -v wireshark` and ensure no vulnerable wireshark package remains installed. Validate container images, analyst workstations, forensic tool images, and CI/SOC automation images, not only servers. Confirm that running processes were restarted after upgrade so old vulnerable binaries are not still resident in memory. If the package cannot be upgraded, verify compensating controls: untrusted captures are processed only in isolated sandboxes, Wireshark/tshark does not run as root, and automated parsing of externally supplied captures is disabled or constrained.

Typical attack path

1. Identify an organization or workflow that uses vulnerable Wireshark/tshark packages to inspect untrusted network captures or live traffic.
2. Create or obtain a crafted packet capture or traffic sequence that triggers the vulnerable parsing condition.
3. Deliver the malicious capture through email, ticket attachments, incident-response evidence packages, shared repositories, or generate equivalent traffic where sensors will capture and parse it.
4. Wait for an analyst, automation job, or monitoring process to open or process the capture with vulnerable Wireshark components.
5. Cause the Wireshark/tshark process to crash, disrupt analysis, or potentially gain execution within the parser process context if the underlying condition permits memory-corruption exploitation.
6. Use any achieved execution to access local files, credentials, case data, or pivot within the analyst or monitoring environment.

How to detect it

To determine whether this was already exploited, review endpoint, EDR, and system logs from hosts that run Wireshark, tshark, or dumpcap. Focus on the period when untrusted pcap/pcapng files were opened, imported, emailed, downloaded, or processed by automation. Look for abnormal process termination, segmentation faults, core dumps, crash reports, or repeated failures involving `wireshark`, `tshark`, `dumpcap`, or related dissector libraries. Correlate crashes with recently accessed capture files, email attachments, case-management downloads, shared-drive files, or automated ingestion queues. Investigate any unexpected child processes, shell execution, file writes, credential access, or outbound network connections originating from Wireshark/tshark processes, because those behaviors are not typical for passive packet analysis. On Linux/Alpine systems, check syslog, kernel logs, auditd, shell history, EDR process trees, container logs, and core dump locations. No unique public exploit string is derivable from the supplied data, so detection should be behavior- and telemetry-based rather than relying on a single signature.

• wireshark
• tshark
• dumpcap
• wireshark-2.2.13
• wireshark-2.2.13-r
• wireshark-2.2.12
• wireshark-2.2.11
• Segmentation fault
• segfault
• core dumped
• /usr/bin/wireshark
• /usr/bin/tshark
• /usr/bin/dumpcap
• /var/lib/systemd/coredump/
• /var/crash/
• /tmp/wireshark
• /tmp/wireshark_pcapng_
• pcapng
• pcap

What your security team should do

• Prioritize upgrade of all Alpine v3.5 Wireshark installations to wireshark 2.2.14-r0 or later because exploit maturity is weaponized and EPSS is extremely high.
• Inventory analyst workstations, packet-capture appliances, forensic containers, SOC automation jobs, and CI pipelines for vulnerable Wireshark/tshark usage.
• Treat packet captures from third parties, incident tickets, malware sandboxes, and external cases as untrusted input; open them only in isolated, disposable environments until remediation is complete.
• Ensure Wireshark, tshark, and dumpcap are not run with unnecessary elevated privileges; prefer least-privilege users and sandboxing.
• Search endpoint and EDR telemetry for Wireshark/tshark crashes or unexpected child processes spawned by Wireshark-related binaries.
• Add monitoring for automated jobs that process pcap or pcapng files and alert on abnormal exits, segmentation faults, core dumps, or new outbound connections from analysis hosts.
• If Alpine v3.5 is still in use, plan migration to a supported operating-system baseline because legacy repositories may expose additional unpatched risk.