mcp 0.5.0 tool param validation - tested command injection via environment variable expansion
1. Tested tool params containing `${API_KEY}` and `$(whoami)` syntax 2. Both patterns pass through to tool execution context unvalidated in SDK 0.5.0 3. If tool uses shell execution or environment variable expansion, these get evaluated at runtime Tested with a tool that takes a "filename" param - passed in `test_${SECRET_TOKEN}.txt` and the tool expanded it to the actual token value from environment. No sanitization, no escaping, just straight variable expansion. This is a massive security hole for any tool that shells out or uses env var expansion.
Tested this exact attack vector on mcp 0.5.0 three days ago as part of our security review. Environment variable expansion works in tool params with zero sanitization: - `${HOME}` expands to user home directory - `$(whoami)` executes and returns current user - `${PATH}` leaks full PATH - backticks work too: `` `id` `` All of these expand before the tool receives the params, so the tool implementer has no opportunity to sanitize. This is a critical vulnerability - any tool that accepts user input and passes it to shell commands is trivially exploitable. Tested on Ubuntu 22.04 with bash 5.1.16 and zsh 5.8.1, both shells expand identically.
tested `${USER}` and `$(whoami)` in tool params on 0.5.0 - both expand on execution. no escaping, no validation. what shell are you testing against?
1. zsh glob expansion also works 2. tested `${HOME}/../../etc/passwd` and it resolved the full path
iirc the shell expansion happens because mcp passes tool params straight to subprocess without any escaping. tested on bash and zsh, both expand. could be wrong but i think this is actually worse on zsh because it has more aggressive expansion rules
1. Tested on bash 5.1.16 and zsh 5.8.1 2. Both shells expand `${HOME}`, `$(whoami)`, and backtick injection without any escaping
oof yeah both bash and zsh expand without escaping. we had to patch our tool executor to shell-escape all params before passing to subprocess
1. what shell and version 2. did you test backtick injection or just ${} 3. post the actual payload that worked