MCP-for-Stata: Command injection via log_file_name parameter in Stata command wrapperGHSA-4p62-hqp5-g644
Fix: SepineTam/mcp-for-stata@e6f9459GHSA-4p62-hqp5-g644 is a CWE-77 vulnerability in stata-mcp. A fix is available for stata-mcp — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-4p62-hqp5-g644.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
stata-mcpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The log_file_name parameter in the stata_do API and CLI is directly interpolated into a Stata command string without sanitization. The security guard (GuardValidator) only scans the do-file content but does not validate this parameter. An attacker can inject arbitrary Stata commands (including shell, python, erase, etc.) by crafting a malicious log_file_name containing quotes, newlines, or Stata command separators.
Details
In src/stata_mcp/stata/stata_do/do.py, both _execute_unix_like and _execute_windows construct a Stata command string using Python f-strings:
commands = f"""
capture log close
{self.generate_log_command(log_file, is_replace)}
...
do "{dofile_path}"
...
"""
The generate_log_command method returns:
log_cmd = f'log using "{log_file.as_posix()}", {replace_clause} {log_type} name({log_type}_log)'
Where log_file is constructed from user-supplied log_name:
def generate_log_file(self, log_name: str, extension='log'):
return self.log_file_path / f"{log_name}.{extension}"
The log_name parameter comes directly from user input (via MCP tool stata_do or CLI stata-mcp tool do) without any validation. Since the path is embedded inside double quotes in a Stata command string, an attacker can break out of the string context and inject arbitrary commands.
Additionally, generate_log_file does not prevent path traversal via log_name, allowing arbitrary file write outside the intended log directory.
Proof of Concept
When calling stata_do via MCP tool with:
{
"dofile_path": "test.do",
"log_file_name": "'; shell echo pwned > /tmp/pwned.txt; '"
}
The generated Stata commands become:
log using "<log_dir>/'; shell echo pwned > /tmp/pwned.txt; '.log", replace text name(text_log)
Stata interprets this as multiple commands, with shell echo pwned > /tmp/pwned.txt; executed as an arbitrary shell command.
Impact
- Remote Code Execution via
shellcommand injection - Arbitrary file write/overwrite via path traversal in
log_name - Complete bypass of the security guard, as the guard only validates do-file content, not wrapper parameters
Remediation / Fix
- Apply strict allowlist validation to
log_name(only alphanumeric, underscore, dot, hyphen; max 128 chars) - Resolve and verify the constructed log path remains within the intended log directory
- Consider generating safe internal filenames (e.g., UUIDs) instead of accepting user-defined log names for command construction
- Apply similar sanitization to
dofile_pathbefore embedding it into Stata command strings
References
- Issue: #74
- Fix commit: https://github.com/SepineTam/stata-mcp/commit/e6f945941ae0c7cf5e74a428e0b3dc82b396382f
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | stata-mcp | all versions | 1.17.3pip install --upgrade 'stata-mcp==1.17.3' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for stata-mcp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update stata-mcp to 1.17.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4p62-hqp5-g644 is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Frequently Asked Questions
Is GHSA-4p62-hqp5-g644 in your dependencies?
Find it across PyPI, including transitive dependencies.