Is jgm2025/veeam-mcp safe?
https://github.com/openclaw/skills/tree/main/skills/jgm2025/veeam-mcp
The jgm2025/veeam-mcp skill contains no active prompt injection, no canary file exfiltration, and only expected network behavior during installation. However, it has significant security design concerns: it depends entirely on a separately-obtained beta Docker image that cannot be verified at install time, passes plaintext Veeam admin credentials as Docker environment variables to that unverifiable container, and disables TLS certificate verification for all Veeam server connections — creating a layered credential exposure and supply chain risk for administrators of backup infrastructure. The skill is not malicious as written but its credential handling design and external dependency make it unsuitable for deployment without careful review of the Docker image provenance and organizational tolerance for these risks.
Category Scores
Findings (11)
HIGH Veeam admin password passed as plaintext Docker environment variable -25 ▶
All four shell scripts (query-veeam.sh, test-connection.sh, list-tools.sh, start-mcp.sh) read Veeam admin credentials from ~/.veeam-mcp-creds.json and pass them as Docker -e environment variables ADMIN_USERNAME and ADMIN_PASSWORD. Any malicious or compromised instance of the veeam-intelligence-mcp-server Docker image receives these credentials in cleartext at container startup. Docker environment variables are also visible via docker inspect to any process with Docker socket access.
HIGH TLS certificate verification disabled for all Veeam connections -10 ▶
Every script passes ACCEPT_SELF_SIGNED_CERT=true to the Docker container, disabling certificate validation for HTTPS connections to Veeam B&R (port 443) and Veeam ONE (port 1239). This enables man-in-the-middle attacks on any network path between the Docker container and the Veeam servers, allowing interception of admin credentials and API responses including backup metadata.
HIGH Unverifiable external Docker image dependency creates supply chain risk -30 ▶
The skill's core functionality depends on a beta Docker image veeam-intelligence-mcp-server that is explicitly NOT included in this skill package. Users must obtain it separately from Veeam with no verification mechanism provided. The SKILL.md directs users to 'Contact Veeam directly or your Veeam account representative' or check 'official channels.' If a user inadvertently builds or pulls this image from an unofficial source, the container receives full Veeam admin credentials and MCP API access to backup infrastructure.
MEDIUM Unvalidated $PRODUCT variable used in jq path expressions before input sanitization -10 ▶
In test-connection.sh and list-tools.sh, the $PRODUCT variable from command-line argument is interpolated directly into a jq path expression before any validation occurs. A crafted value such as 'vbr | .someotherkey' could cause jq to traverse and return unintended fields from the credentials JSON, potentially leaking credential data for additional configured servers. In query-veeam.sh, validation of 'vbr' vs 'vone' occurs after the jq extraction.
MEDIUM Backup infrastructure access enables high-impact secondary attacks -25 ▶
This skill grants an LLM agent natural language control over Veeam Backup & Replication and Veeam ONE with administrator credentials. An adversarial prompt injection from a backup job name or repository description, or a compromised agent session, could use this access to enumerate all protected VMs, delete or disable backup jobs, corrupt backup repositories, or export sensitive backup metadata — actions that would undermine disaster recovery capabilities and could facilitate ransomware attacks.
MEDIUM Admin credentials stored in plaintext local JSON file -5 ▶
The skill instructs users to create ~/.veeam-mcp-creds.json containing Veeam admin usernames and passwords in plaintext. While chmod 600 is recommended, any process running as the same user — including the LLM agent with filesystem access — can read this file. This also means backup infrastructure credentials persist on disk indefinitely rather than being supplied ephemerally.
MEDIUM Shell scripts invoke Docker with credentials — execution boundary risk -15 ▶
The four shell scripts constitute executable code that, when invoked by the agent, create Docker containers with elevated privileges in the user's environment. The scripts use set -euo pipefail which provides some protection but the overall pattern of credential-laden Docker invocations driven by agent decisions expands the attack surface for prompt injection to trigger unintended Docker operations.
LOW Skill instructs agent to access credential files and run Docker commands -7 ▶
While not adversarial, SKILL.md directs the agent to interact with sensitive credential files and execute Docker commands as part of its normal workflow. This expands the agent's implicit permission surface compared to skills that operate only via declared MCP tools.
LOW Installation deferred — Docker image risk surface cannot be evaluated at clone time -10 ▶
The git clone installs only documentation and shell scripts. The actual runtime component (Docker image) is explicitly deferred to a separate acquisition process outside this skill's repository. The security posture of the skill as installed cannot be fully assessed without evaluating the Docker image, which is beta software with no public image hash or verification mechanism referenced.
INFO All canary files intact — no exfiltration via honeypots 0 ▶
The audit framework's honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) were accessed only by the audit framework itself at timestamps 1771928248 (pre-install baseline) and 1771928270 (post-install integrity check). No skill process accessed or modified any canary file.
INFO Clone network activity limited to expected GitHub connection 0 ▶
Network monitoring confirms the install made a single HTTPS connection to GitHub (140.82.121.3:443) to clone the monorepo. The connection diff shows no new persistent listeners or connections after install. Pre-existing connections to Ubuntu infrastructure are OS-level background activity.