Skip to content

MCP-for-Stata log_file_name command-injection boundary

Operator value

GitHub advisory GHSA-4p62-hqp5-g644 / CVE-2026-47708 describes command injection in stata-mcp before 1.17.3: the user-controlled log_file_name parameter for the stata_do MCP tool and stata-mcp tool do CLI is embedded into a generated Stata command string without validation.

For authorized testing, treat this as an agent-tool wrapper boundary. The do-file guard scans Stata script content, but wrapper parameters can still alter the command stream that the tool sends to Stata.

Affected surface

  • Product/package: MCP-for-Stata / stata-mcp
  • Ecosystem: Python / pip
  • Affected versions: < 1.17.3
  • Fixed version: 1.17.3
  • Required position: ability to influence MCP tool arguments or CLI parameters for a host that has Stata and stata-mcp installed
  • Risk pattern: tool wrappers that validate primary script/input content but interpolate auxiliary parameters into an interpreter command string

Recon workflow

  1. Confirm the target is in scope and that agent-tool testing is explicitly authorized.
  2. Inventory MCP/Stata usage from authorized evidence:
  3. MCP server configs that expose a Stata tool;
  4. Python dependency manifests containing stata-mcp;
  5. agent harness logs or tool catalogs showing stata_do;
  6. CLI usage of stata-mcp tool do in notebooks, CI jobs, or analyst workstations.
  7. Verify the installed version from a lab replica or approved shell on the assessed host:
python -m pip show stata-mcp
python -m pip freeze | grep -i '^stata-mcp=='
  1. Identify who can set log_file_name. Prioritize multi-user agent workbenches, shared MCP servers, delegated notebook execution, and any workflow where untrusted prompts or tickets can become tool arguments.
  2. Review adjacent wrapper parameters too. This advisory is about log_file_name, but the durable lesson is that every parameter embedded into generated Stata commands must be treated as code-adjacent input.

Safe validation pattern

Use a lab clone or a disposable test account. The goal is to prove command-stream injection with a harmless canary file, not to run destructive Stata or shell commands.

  1. Prepare an inert do-file:
display "stata-mcp boundary canary"
  1. Send a benign baseline through the same execution path used by the target workflow:
stata-mcp tool do ./canary.do --log-file-name baseline_canary

Expected contained result: the run creates a normal Stata log named from baseline_canary, with no shell side effects.

  1. In a lab only, submit a log_file_name canary that attempts to break the quoted Stata log using command and write a fixed marker to a temporary path:
stata-mcp tool do ./canary.do \
  --log-file-name "'; shell printf stata_mcp_log_boundary_canary >/tmp/stata_mcp_log_boundary_canary; '"
  1. Record the outcome:
  2. Contained: the wrapper rejects the name, escapes it, or writes only a normal log file under the expected log directory.

  3. Vulnerable: the Stata command stream executes the injected shell statement and creates the marker file.

  4. Remove only the inert canary artifact you created:

rm -f /tmp/stata_mcp_log_boundary_canary

MCP harness probe

When testing through an MCP client, keep the same proof bounded to an inert marker. The argument shape from the advisory is:

{
  "dofile_path": "./canary.do",
  "log_file_name": "'; shell printf stata_mcp_log_boundary_canary >/tmp/stata_mcp_log_boundary_canary; '"
}

A valid finding shows that an MCP caller can influence log_file_name, that the target runs a vulnerable stata-mcp version, and that the generated Stata command stream executes an injected command despite any do-file content guard.

Path-traversal companion check

The advisory also notes that log_file_name can be used to construct log paths outside the intended log directory. Validate this separately and non-destructively:

stata-mcp tool do ./canary.do --log-file-name "../stata_mcp_path_boundary_canary"

Capture whether the log path resolves outside the configured log directory. Do not overwrite existing files; use unique canary names and inspect only paths created for the test.

Evidence to capture

  • stata-mcp version and how it was verified.
  • The exact tool path tested: MCP client call, server config, CLI, notebook job, or CI task.
  • Minimal benign and canary request/response pairs.
  • The generated log path or command output proving whether the wrapper escaped, rejected, or executed the canary.
  • Confirmation that the test used inert files and did not access or modify sensitive datasets.

Report framing

Frame this as a tool-wrapper command-injection boundary failure: policy validation covered do-file content, but an auxiliary filename parameter was interpolated into a Stata command string. Impact depends on which identities can call the MCP tool and what OS privileges the Stata process has on the host.

Sources