CVE-2026-55580

mcp-shell` at commit `17ac0eef5c9a5a42b8fb132d3d034973d55a5433` has two issues that together mean neither the default deploy path nor the recommended "secure mode" delivers the restriction they're marketed as providing. Filing these together because the two failure modes bracket the full intended audience — the from-source path gets users who skip security config entirely, the Docker path gets users who follow the security.yaml example and believe they're protected. --- The first issue is in `config.go`, line 49: ```go config := &Config{ Security: SecurityConfig{ Enabled: false, }, ... } ``` Security is opt-in. The bare binary ships with `Enabled: false`, and `security.go` lines 26–29 make the consequence explicit: ```go func (v *SecurityValidator) validateCommand(command string) error { if !v.config.Enabled { v.logger.Debug().Str("command", command).Msg("Security disabled, allowing command") return nil } ``` `main.go` lines 35–39 confirm the deployment condition: ```go configFile := os.Getenv("MCP_SHELL_SEC_CONFIG_FILE") if configFile != "" { log.Info().Str("config_file", configFile).Msg("Loading security config") } else { log.Info().Msg("No security config file specified, security disabled") } ``` The README's from-source install path (lines 22–26) runs `git clone ... && make install && mcp-shell` with no environment variable and no config file. The MCP client config example block (lines 78–85) passes only `MCP_SHELL_LOG_LEVEL` — no `MCP_SHELL_SEC_CONFIG_FILE`. Every operator who follows either documented path runs an unrestricted shell-execution server. **Attack model:** operator installs from source or follows the MCP client config example verbatim. Any LLM connected via stdio can call `shell_exec` with an arbitrary command string — no allowlist, no blocklist, no filtering, no logging. Because mcp-shell is stdio transport, the attacking agent is the operator's own connected LLM — prompt injection or a