T09 · Insecure Skill Coding Practices
- Location
scripts/run_tests.py:10- Finding
Environment Variable Disclosure Through Unsafe Shell Invocation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a simple diagnostic runner, but its default test can expose environment variables and its documentation promotes broad command execution without enough safety boundaries.
Review before installing. Run it only in a low-sensitivity environment, avoid using the environment-variable examples, and do not invoke it from shells or CI jobs that contain tokens or credentials. A safer version should remove the default env check, use shell=False, redact or avoid sensitive output, and replace broad command support with an explicit diagnostic allowlist.
scripts/run_tests.py:10Environment Variable Disclosure Through Unsafe Shell Invocation
The stated purpose is a simple environment verification tool, but the described behavior extends to environment inspection, directory listing, and file writes. That mismatch is dangerous because users may authorize a benign-seeming diagnostic skill that actually exposes sensitive system context or modifies the filesystem.
Using shell=True in a tool-execution helper is a classic tool parameter abuse issue because it delegates argument interpretation to the shell. In a reusable helper that runs multiple commands, this creates a dangerous primitive that can be repurposed for command injection or shell metacharacter abuse, especially in future edits or if command inputs ever become dynamic.
def run_command(cmd, description=""):
"""Run a command and return result."""
try:
result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=30)
return {
'command': ' '.join(cmd),
'description': description,
The skill advertises shell-command execution but does not declare any explicit tool scope or allowed-tools restrictions. In an agent ecosystem, undocumented shell capability increases the chance the skill is invoked with broader execution power than users or orchestrators expect, weakening policy enforcement and review.
The skill description is broad enough to match many generic debugging or troubleshooting prompts, increasing the chance it is selected in contexts where shell execution is unnecessary. Overbroad invocation language is risky because it can cause accidental activation of a powerful skill for low-risk tasks.
The markdown promotes custom command execution and system inspection without warning about privacy, credential exposure, or system-modification risks. Users may reasonably assume diagnostic commands are harmless, leading them to run commands that disclose secrets or affect system state.
Advertising that the skill can 'Run any command' indicates effectively unrestricted shell access. In practice, that grants the skill the ability to execute destructive, persistence-establishing, or data-exfiltrating commands far beyond a simple verification workflow.
- ✅ **Python Availability Check** / **Verificação de Disponibilidade do Python** - Confirms Python 3.x installed
- ✅ **System Command Execution** / **Execução de Comando do Sistema** - Runs and validates system commands
- ✅ **File System Access** / **Acesso ao Sistema de Arquivos** - Verifies directory access and permissions
- ✅ **Custom Command Support** / **Suporte a Comandos Customizados** - Run any command with validation
- ✅ **Working Directory Check** / **Verificação de Diretório de Trabalho** - Confirms current location
- 📝 **Detailed Logging** / **Log Detalhado** - Comprehensive output for debugging
The skill explicitly supports arbitrary custom shell commands, which turns a health-check utility into a general command-execution wrapper. This is dangerous because it can be used to read secrets, alter files, install software, or pivot into broader host compromise under the guise of troubleshooting.
The documentation encourages environment-reading commands like env | head -10, which normalizes exposure of environment variables during routine testing. Environment variables frequently contain tokens, API keys, hostnames, and internal configuration, so even partial output can leak sensitive information.
The code invokes subprocess.run with shell=True while passing commands that are represented as argument lists, which is an unsafe and error-prone pattern. In an agent skill context, shell execution increases the risk of command injection, unexpected shell parsing, and unintended execution if any command components ever become user-influenced or are modified later.
def run_command(cmd, description=""):
"""Run a command and return result."""
try:
result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=30)
return {
'command': ' '.join(cmd),
'description': description,
The skill presents itself as a simple system verification tool, but it also enumerates environment variables and workspace contents, which expands its data access beyond what users would reasonably expect. This mismatch increases the chance of unauthorized disclosure of sensitive operational data during a supposedly harmless test run.
Reading environment variables during a quick test can expose secrets such as tokens, credentials, service endpoints, or internal configuration. Even though the command appears intended to limit output, the implementation is flawed and still represents unnecessary sensitive-data access for the stated purpose.
The environment inspection lacks any warning that command output may contain sensitive information. In an agent environment, even a partial dump of environment variables can leak secrets into logs, transcripts, or downstream systems, making this more dangerous than a normal local diagnostic script.
The script performs a filesystem write to /tmp as part of a quick verification flow without clearly disclosing that side effect. Unexpected writes can violate least surprise, interfere with shared environments, and create persistence artifacts that users did not authorize.
Skill requests more permissions than appear necessary for its stated functionality. Review if elevated access is justified.
## Limitations / Limitações
**User Permissions:** Requires read and execute access to directories
- **Permissões do Usuário:** Requer acesso de leitura e execução a diretórios
- System commands must be in PATH / Comandos do sistema devem estar no PATH
The file write test has a side effect that is not explicitly disclosed to the user, which is a policy and safety concern even if the write target is only /tmp. In an automation context, undisclosed writes can surprise users and complicate forensic or compliance expectations.
No suspicious patterns detected.