These flaws enable an LLM connected to the mcp-shell server to execute arbitrary commands on the underlying system. The attack surface is significant because mcp-shell operates via stdio transport; an attacker (or a compromised/misaligned LLM agent) can issue shell_exec calls that bypass validation either due to the "disabled by default" state or by abusing allowed interpreters to execute nested command strings, effectively bypassing metacharacter filters. These vulnerabilities affect all deployments prior to version 0.6.0, including source-based and official container-based installations.

Attack Chain

1. The operator deploys mcp-shell using default installation steps (git clone or official Docker image).
2. The operator fails to explicitly set the MCP_SHELL_SEC_CONFIG_FILE environment variable, leaving the security module in a disabled state (Finding 1) OR the operator uses the default security.yaml which permits shell interpreters (Finding 2).
3. The attacker (e.g., a malicious or poisoned LLM) establishes a session with the mcp-shell server over the stdio transport.
4. The attacker sends a tools/call request to the mcp-shell server specifying the shell_exec method.
5. The server process receives the command request; if security is disabled, it proceeds directly to system execution.
6. If in "secure mode" with an insecure allowlist, the attacker executes /bin/bash -c '<arbitrary_command>' which the server permits because /bin/bash is on the allowlist and the string contains no forbidden metacharacters.
7. The server process spawns the interpreter, which in turn executes the embedded malicious payload.
8. The attacker achieves arbitrary code execution on the host with the privileges of the mcp-shell process.

Impact

Successful exploitation allows for full arbitrary command execution on the host system running mcp-shell. Given that mcp-shell is designed to interact with LLMs, this can result in unauthorized data exfiltration, system configuration changes, and lateral movement from the host. Because the threat model involves LLMs acting as the agent, the vulnerability is reachable without network-level access, provided the LLM has been tricked or configured to invoke the shell_exec tool.

Recommendation

1. Upgrade mcp-shell to version 0.6.0 or higher immediately to address the insecure default configurations and updated example allowlists.
2. For existing deployments, manually create a restrictive security.yaml that excludes all shell interpreters (e.g., bash, sh, python, perl, ruby) and enforce Enabled: true in the configuration.
3. Set the MCP_SHELL_SEC_CONFIG_FILE environment variable explicitly in all deployment environments (including Kubernetes/Docker orchestrators) to ensure validation is active.
4. Implement strict sandboxing (e.g., Docker containers with minimal capabilities or separate namespaces) for mcp-shell processes as a layer of defense-in-depth, acknowledging that sandboxing does not mitigate the primary vulnerability of unauthorized intra-session command execution.