GHSA-4p62-hqp5-g644
Fix: SepineTam/mcp-for-stata@e6f9459GHSA-4p62-hqp5-g644 is a CWE-77 vulnerability in stata-mcp. O3 Security confirms whether GHSA-4p62-hqp5-g644 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
MCP-for-Stata: Command injection via log_file_name parameter in Stata command wrapper
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
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
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.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-4p62-hqp5-g644 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-4p62-hqp5-g644. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-4p62-hqp5-g644 in your dependencies?
O3 detects GHSA-4p62-hqp5-g644 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.