### 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: ```python commands = f""" capture log close {self.generate_log_command(log_file, is_replace)} ... do "{dofile_path}" ... """ ``` The `generate_log_command` method returns: ```python 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`: ```python 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: ```json { "dofile_path": "test.do", "log_file_name": "'; shell echo pwned > /tmp/pwned.txt; '" } ``` The generated Stata commands become: ```stata 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 `shell` command 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 1. Apply strict allowlist validation to `log_name` (only alphanumeric, underscore, dot, hyphen; max 128 chars) 2. Resolve and verify the constructed log path remains within the intended log directory 3. Consider generating safe internal filenames (e.g., UUIDs) instead of accepting user-defined log names for command construction 4. Apply similar sanitization to `dofile_path` before embedding it into Stata command strings ### References - Issue: #74 - Fix commit: https://github.com/SepineTam/stata-mcp/commit/e6f945941ae0c7cf5e74a428e0b3dc82b396382f
### 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: ```python commands = f""" capture log close {self.generate_log_command(log_file, is_replace)} ... do "{dofile_path}" ... """ ``` The `generate_log_command` method returns: ```python 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`: ```python 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: ```json { "dofile_path": "test.do", "log_file_name": "'; shell echo pwned > /tmp/pwned.txt; '" } ``` The generated Stata commands become: ```stata 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 `shell` command 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 1. Apply strict allowlist validation to `log_name` (only alphanumeric, underscore, dot, hyphen; max 128 chars) 2. Resolve and verify the constructed log path remains within the intended log directory 3. Consider generating safe internal filenames (e.g., UUIDs) instead of accepting user-defined log names for command construction 4. Apply similar sanitization to `dofile_path` before embedding it into Stata command strings ### References - Issue: #74 - Fix commit: https://github.com/SepineTam/stata-mcp/commit/e6f945941ae0c7cf5e74a428e0b3dc82b396382f
Update stata-mcp to 1.17.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanMCP-for-Stata: Command injection via log_file_name parameter in Stata command wrapper affects stata-mcp (pip). Severity is critical. ### 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: ```python commands = f""" capture log close {self.generate_log_command(log_file, is_replace)} ... do "{dofile_path}" ... """ ``` The `generate_log_command` method returns: ```python 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`: ```python 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: ```json { "dofile_path": "test.do", "log_file_name": "'; shell echo pwned > /tmp/pwned.txt; '" } ``` The generated Stata commands become: ```stata 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 `shell` command 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 1. Apply strict allowlist validation to `log_name` (only alphanumeric, underscore, dot, hyphen; max 128 chars) 2. Resolve and verify the constructed log path remains within the intended log directory 3. Consider generating safe internal filenames (e.g., UUIDs) instead of accepting user-defined log names for command construction 4. Apply similar sanitization to `dofile_path` before embedding it into Stata command strings ### References - Issue: #74 - Fix commit: https://github.com/SepineTam/stata-mcp/commit/e6f945941ae0c7cf5e74a428e0b3dc82b396382f
AI coding agents often install or upgrade packages automatically in pip. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| stata-mcppip | <1.17.3 | 1.17.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate stata-mcp to 1.17.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanMCP-for-Stata: Command injection via log_file_name parameter in Stata command wrapper affects stata-mcp (pip). Severity is critical. ### 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: ```python commands = f""" capture log close {self.generate_log_command(log_file, is_replace)} ... do "{dofile_path}" ... """ ``` The `generate_log_command` method returns: ```python 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`: ```python 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: ```json { "dofile_path": "test.do", "log_file_name": "'; shell echo pwned > /tmp/pwned.txt; '" } ``` The generated Stata commands become: ```stata 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 `shell` command 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 1. Apply strict allowlist validation to `log_name` (only alphanumeric, underscore, dot, hyphen; max 128 chars) 2. Resolve and verify the constructed log path remains within the intended log directory 3. Consider generating safe internal filenames (e.g., UUIDs) instead of accepting user-defined log names for command construction 4. Apply similar sanitization to `dofile_path` before embedding it into Stata command strings ### References - Issue: #74 - Fix commit: https://github.com/SepineTam/stata-mcp/commit/e6f945941ae0c7cf5e74a428e0b3dc82b396382f
AI coding agents often install or upgrade packages automatically in pip. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| stata-mcppip | <1.17.3 | 1.17.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard