Clawhub Skill Deploy Pilot

• Outcome: Review
• Latest audit: May 28, 2026 · 8:54 AM UTC
• Version: 1.0.0

Overview

This deployment skill mostly fits its purpose, but it advertises important safety controls that are missing while allowing high-impact Docker, SSH, and shell-command execution.

Install only if you will treat every stack definition, health check, and hook as trusted code. Do not rely on the advertised approval, rollback, blue-green, LXC, cron, or history features without verifying or adding them, and run the tool with the least Docker, SSH, and Proxmox privileges needed.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Behavioral AST: exec() Call, eval() Call, Dynamic Import
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (10)

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

command = check.get("command", "echo ok")
        
        try:
            result = subprocess.run(
                ["ssh", target, command],
                capture_output=True,
                text=True,

• Confidence: 88% confidence
• Finding: The SSH health check executes a remote command taken directly from configuration, allowing arbitrary command execution on the target host if the health-check definition is untrusted or attacker-modified. In a deployment automation skill, this is especially dangerous because operators may run it with privileged SSH access to production systems, turning configuration tampering into remote code execution.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

script = check.get("script", "")
        
        try:
            result = subprocess.run(
                script,
                shell=True,
                capture_output=True,

• Confidence: 99% confidence
• Finding: This code executes a configuration-supplied script with shell=True, which is direct arbitrary command execution on the local system. In deployment tooling, the process may run with elevated privileges or access to secrets, Docker, and production credentials, making this a high-risk RCE vector from malicious or compromised stack configuration.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

for hook in stack.get("hooks", {}).get("pre", []):
            print(f"{Colors.status_wait()} Running pre-hook: {hook}")
            try:
                subprocess.run(hook, shell=True, check=True)
                print(f"{Colors.status_ok()} Pre-hook completed")
            except subprocess.CalledProcessError as e:
                print(f"{Colors.status_fail()} Pre-hook failed: {e}")

• Confidence: 99% confidence
• Finding: Pre-deploy hooks are executed with shell=True using hook strings from stack state, enabling arbitrary local command execution. Because hooks run automatically during deployment, any attacker who can modify stack configuration gains reliable code execution in the operator's environment before the deployment even begins.

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

for hook in stack.get("hooks", {}).get("post", []):
                print(f"{Colors.status_wait()} Running post-hook: {hook}")
                try:
                    subprocess.run(hook, shell=True, check=True)
                    print(f"{Colors.status_ok()} Post-hook completed")
                except subprocess.CalledProcessError as e:
                    print(f"{Colors.status_fail()} Post-hook failed: {e}")

• Confidence: 99% confidence
• Finding: Post-deploy hooks are executed with shell=True from configuration, creating another arbitrary command execution path. Since these run after a successful deployment, they may be trusted and overlooked, allowing an attacker to persist, exfiltrate secrets, or tamper with deployed infrastructure.

Intent-Code Divergence

Medium

• Confidence: 86% confidence
• Finding: The docstring advertises approval workflows and zero-downtime controls, but the implementation contains no approval enforcement and exposes options to bypass checks. This mismatch can create a false sense of security, leading operators to use the tool in sensitive production contexts without the governance controls they believe are present.

Intent-Code Divergence

Medium

• Confidence: 87% confidence
• Finding: The tool claims rollback support, but rollback is effectively a stub and auto-rollback only stops containers rather than restoring a prior known-good state. In production deployment tooling, this can worsen outages and recovery time because operators may rely on rollback behavior that does not actually exist.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill explicitly documents `--skip-health-check` and `--force` as normal deployment options in an infrastructure automation tool, but does not place strong inline warnings at the point of use about bypassing approval and safety validation. In this context, those flags can directly enable unsafe or unauthorized production changes, increasing the likelihood of outages, bad deploys, or policy bypass by users following examples verbatim.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The custom script health-check feature silently permits arbitrary shell command execution without prominently disclosing that risk. In this context, a 'health check' sounds harmless, which makes the feature more dangerous because users may import or trust configurations that actually contain executable payloads.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: Pre- and post-deploy hooks execute shell commands but are not clearly disclosed as arbitrary code execution mechanisms. In deployment tooling, hidden execution surfaces are especially risky because imported stack definitions may appear declarative while actually running attacker-controlled commands.

Vague Triggers

Medium

• Confidence: 84% confidence
• Finding: The skill metadata uses broad, generic trigger terms such as "deploy" and "automation" without any apparent scoping or activation constraints. In an agent ecosystem, this can cause the skill to activate during routine DevOps conversations and expose high-impact capabilities like Docker, SSH, or Proxmox execution when the user did not explicitly intend to invoke deployment automation.

VirusTotal

65/65 vendors flagged this skill as clean.

Static analysis

No suspicious patterns detected.