wireshark-mcp CVE-2026-43901
MEDIUMSeverity by source
AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
Description
Impact
wireshark-mcp exposes a wireshark_export_objects MCP tool that accepts an attacker-controlled dest_dir parameter and passes it to tshark's --export-objects flag with no mandatory path restriction.
The path sandbox (_allowed_dirs) is None by default and only activates when the environment variable WIRESHARK_MCP_ALLOWED_DIRS is explicitly set. In a default installation, any directory on the filesystem can be used as the export destination.
Affected code (src/wireshark_mcp/tshark/client.py:531-543):
output_validation = self._validate_output_path(dest_dir)
# _validate_output_path only enforces the sandbox when _allowed_dirs is set.
# Default: _allowed_dirs = None → no restriction.
os.makedirs(dest_dir, exist_ok=True)
# creates arbitrary directories
cmd = [..., "--export-objects", f"{protocol},{dest_dir}"]
Attack Scenario
An attacker embeds a crafted HTTP response in a pcap file (e.g. Content-Disposition: filename=authorized_keys). Via prompt injection in the pcap payload, an AI model using this MCP server is manipulated into calling wireshark_export_objects with:
dest_dir=/home/user/.ssh/
tshark then extracts and writes the HTTP object to that path, granting the attacker SSH access.
The same technique can target:
/etc/cron.d/- Writable web roots
- Other sensitive filesystem locations
Additional Affected Operations
The same missing sandbox affects:
merge_pcap_fileseditcap_trimeditcap_spliteditcap_time_shifteditcap_deduplicatetext2pcap_import
Proof of Concept
Confirmed on wireshark-mcp v1.1.5 with tshark 4.6.4.
A crafted pcap’s HTTP object was successfully written to an arbitrary filesystem path when:
_allowed_dirs = None
---
Patches
Not yet patched.
A fix should make the path sandbox mandatory for all file-write operations rather than optional:
# Reject all write operations when no sandbox is configured
if not self._allowed_dirs:
return json.dumps({
"success": False,
"error": {
"type": "SecurityError",
"message": "Set WIRESHARK_MCP_ALLOWED_DIRS before using file-write operations"
}
})
---
Workarounds
Set WIRESHARK_MCP_ALLOWED_DIRS to a restricted safe directory before starting the server:
export WIRESHARK_MCP_ALLOWED_DIRS=/tmp/wireshark_mcp_safe
This activates the existing sandbox and blocks writes outside the allowed path.
---
Resources
- Vulnerable code:
src/wireshark_mcp/tshark/client.pylines 521-543src/wireshark_mcp/tshark/client.pylines 685-839- CWE-22: Improper Limitation of a Pathname to a Restricted Directory
- CWE-73: External Control of File Name or Path
AnalysisAI
Arbitrary file write in wireshark-mcp up to version 1.1.5 allows remote attackers to write files to any filesystem location via prompt injection in pcap payloads that trigger the wireshark_export_objects MCP tool. The vulnerability exploits missing mandatory path restrictions when the WIRESHARK_MCP_ALLOWED_DIRS environment variable is not configured (default state). An attacker can craft a malicious pcap with embedded HTTP objects bearing filenames like authorized_keys, manipulate an AI model using the MCP server into calling export_objects with dest_dir=/home/user/.ssh/, and achieve SSH access, cron hijacking, or web shell placement. Publicly available proof of concept confirms exploitation against version 1.1.5 with tshark 4.6.4; no vendor-released patch exists at time of analysis.
Technical ContextAI
wireshark-mcp is a Python MCP (Model Context Protocol) server that wraps tshark (Wireshark's command-line packet analyzer) for use by AI models. The vulnerability resides in src/wireshark_mcp/tshark/client.py (lines 521-543 and 685-839), where file-write operations (_validate_output_path, wireshark_export_objects, merge_pcap_files, editcap_trim, editcap_split, editcap_time_shift, editcap_deduplicate, text2pcap_import) lack mandatory path sandboxing. The _allowed_dirs attribute defaults to None and is only activated when the WIRESHARK_MCP_ALLOWED_DIRS environment variable is explicitly set. When unset, os.makedirs(dest_dir, exist_ok=True) and tshark's --export-objects flag accept arbitrary attacker-controlled paths. The root cause (CWE-22: Improper Limitation of a Pathname to a Restricted Directory; CWE-73: External Control of File Name or Path) stems from optional rather than mandatory validation-the sandbox exists in code but is disabled by default. The attack surface includes prompt injection via malicious pcap payloads that manipulate AI models into calling these tools with crafted parameters.
RemediationAI
No vendor-released patch is available at time of analysis. Users must immediately set the WIRESHARK_MCP_ALLOWED_DIRS environment variable to a restricted, non-sensitive directory before starting the wireshark-mcp server; for example, export WIRESHARK_MCP_ALLOWED_DIRS=/tmp/wireshark_mcp_safe. This activates the existing but optional sandbox and restricts all file-write operations to the designated path, preventing writes to /home/user/.ssh/, /etc/cron.d/, or other sensitive locations. Additional compensating controls include running wireshark-mcp in a containerized environment (e.g., Docker) with read-only root filesystem and minimal host mounts, restricting the MCP server's process privileges via AppArmor or SELinux to deny file write access outside permitted directories, and isolating the MCP server on a network segment with strict egress filtering to prevent automated recon or lateral movement if compromise occurs. Users should monitor the GitHub advisory (https://github.com/bx33661/Wireshark-MCP/security/advisories/GHSA-3r68-x3xc-rxpg) for patch availability. Until patched, do not deploy wireshark-mcp in trusted environments without WIRESHARK_MCP_ALLOWED_DIRS set; using it with default settings allows remote arbitrary file write.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same weakness CWE-22 – Path Traversal
View allSame technique Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-3r68-x3xc-rxpg