Trust Assessment
veeam-mcp received a trust score of 10/100, placing it in the Untrusted category. This skill has significant security findings that require attention before use in production.
SkillShield's automated analysis identified 20 findings: 0 critical, 4 high, 12 medium, and 4 low severity. Key findings include Sensitive environment variable access: $HOME, Sensitive environment variable access: $USER, Supply Chain Risk: Unverified Docker Image Source and Beta Software.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 4/100, indicating areas for improvement.
Last analyzed on February 14, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings20
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| HIGH | Supply Chain Risk: Unverified Docker Image Source and Beta Software The skill relies on a proprietary 'Veeam Intelligence MCP server' which is explicitly stated to be in beta. Users are instructed to obtain this server by contacting Veeam directly or via community forums, and then build a Docker image from an unspecified local source. This process lacks standard secure software supply chain practices (e.g., trusted registries, image signing, version pinning, public source code review), making it highly vulnerable to tampering or distribution of malicious software. Beta software also inherently carries a higher risk of containing vulnerabilities. Recommend obtaining the Docker image from a trusted, verified registry with image signing. If building from source, provide clear instructions for verifying the source code's integrity (e.g., checksums, GPG signatures). Advise extreme caution with beta software in production environments. | LLM | SKILL.md:49 | |
| HIGH | Command Injection: Unsanitized 'PRODUCT' variable in Docker command The 'PRODUCT' variable, derived directly from user input ($1), is unsanitized and directly interpolated into the 'docker run' command string as part of an environment variable definition (-e 'PRODUCT_NAME=$PRODUCT'). An attacker could craft the $1 argument (e.g., 'vbr" --env EVIL_VAR=true #') to inject arbitrary Docker command-line options or environment variables. This could lead to privilege escalation (e.g., mounting host paths), data exfiltration, or other malicious actions within the Docker execution context. Validate the 'PRODUCT' variable against an explicit whitelist (e.g., 'vbr', 'vone') before using it in the command. Alternatively, use 'printf %q' or similar shell quoting mechanisms to properly escape the variable if it must be interpolated directly. | LLM | scripts/list-tools.sh:27 | |
| HIGH | Command Injection: Unsanitized 'PRODUCT' variable in Docker command The 'PRODUCT' variable, derived directly from user input ($1), is unsanitized and directly interpolated into the 'docker run' command string as part of an environment variable definition (-e 'PRODUCT_NAME=$PRODUCT'). An attacker could craft the $1 argument (e.g., 'vbr" --env EVIL_VAR=true #') to inject arbitrary Docker command-line options or environment variables. This could lead to privilege escalation (e.g., mounting host paths), data exfiltration, or other malicious actions within the Docker execution context. Validate the 'PRODUCT' variable against an explicit whitelist (e.g., 'vbr', 'vone') before using it in the command. Alternatively, use 'printf %q' or similar shell quoting mechanisms to properly escape the variable if it must be interpolated directly. | LLM | scripts/start-mcp.sh:24 | |
| HIGH | Command Injection: Unsanitized 'PRODUCT' variable in Docker command The 'PRODUCT' variable, derived directly from user input ($1), is unsanitized and directly interpolated into the 'docker run' command string as part of an environment variable definition (-e 'PRODUCT_NAME=$PRODUCT'). An attacker could craft the $1 argument (e.g., 'vbr" --env EVIL_VAR=true #') to inject arbitrary Docker command-line options or environment variables. This could lead to privilege escalation (e.g., mounting host paths), data exfiltration, or other malicious actions within the Docker execution context. Validate the 'PRODUCT' variable against an explicit whitelist (e.g., 'vbr', 'vone') before using it in the command. Alternatively, use 'printf %q' or similar shell quoting mechanisms to properly escape the variable if it must be interpolated directly. | LLM | scripts/test-connection.sh:28 | |
| MEDIUM | Sensitive environment variable access: $HOME Access to sensitive environment variable '$HOME' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/jgm2025/veeam-mcp/scripts/list-tools.sh:10 | |
| MEDIUM | Sensitive environment variable access: $USER Access to sensitive environment variable '$USER' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/jgm2025/veeam-mcp/scripts/list-tools.sh:34 | |
| MEDIUM | Sensitive environment variable access: $HOME Access to sensitive environment variable '$HOME' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/jgm2025/veeam-mcp/scripts/query-veeam.sh:20 | |
| MEDIUM | Sensitive environment variable access: $USER Access to sensitive environment variable '$USER' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/jgm2025/veeam-mcp/scripts/query-veeam.sh:68 | |
| MEDIUM | Sensitive environment variable access: $HOME Access to sensitive environment variable '$HOME' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/jgm2025/veeam-mcp/scripts/start-mcp.sh:10 | |
| MEDIUM | Sensitive environment variable access: $USER Access to sensitive environment variable '$USER' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/jgm2025/veeam-mcp/scripts/start-mcp.sh:32 | |
| MEDIUM | Sensitive environment variable access: $HOME Access to sensitive environment variable '$HOME' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/jgm2025/veeam-mcp/scripts/test-connection.sh:10 | |
| MEDIUM | Sensitive environment variable access: $USER Access to sensitive environment variable '$USER' detected in shell context. Verify this environment variable access is necessary and the value is not exfiltrated. | Static | skills/jgm2025/veeam-mcp/scripts/test-connection.sh:33 | |
| MEDIUM | Excessive Permissions: Acceptance of Self-Signed Certificates The Docker container is configured to accept self-signed certificates (`-e "ACCEPT_SELF_SIGNED_CERT=true"`). While this might be necessary in some enterprise environments, it weakens the security posture by disabling proper certificate validation. This makes the communication between the MCP server and the Veeam APIs vulnerable to Man-in-the-Middle (MITM) attacks, where an attacker could intercept and potentially modify sensitive data, including credentials or query results. Advise users to only enable `ACCEPT_SELF_SIGNED_CERT=true` in controlled environments where the risk is understood and mitigated. Ideally, recommend configuring proper certificate authorities (CAs) or using valid, trusted certificates for Veeam servers to ensure secure communication without disabling validation. | LLM | scripts/list-tools.sh:29 | |
| MEDIUM | Excessive Permissions: Acceptance of Self-Signed Certificates The Docker container is configured to accept self-signed certificates (`-e "ACCEPT_SELF_SIGNED_CERT=true"`). While this might be necessary in some enterprise environments, it weakens the security posture by disabling proper certificate validation. This makes the communication between the MCP server and the Veeam APIs vulnerable to Man-in-the-Middle (MITM) attacks, where an attacker could intercept and potentially modify sensitive data, including credentials or query results. Advise users to only enable `ACCEPT_SELF_SIGNED_CERT=true` in controlled environments where the risk is understood and mitigated. Ideally, recommend configuring proper certificate authorities (CAs) or using valid, trusted certificates for Veeam servers to ensure secure communication without disabling validation. | LLM | scripts/query-veeam.sh:56 | |
| MEDIUM | Excessive Permissions: Acceptance of Self-Signed Certificates The Docker container is configured to accept self-signed certificates (`-e "ACCEPT_SELF_SIGNED_CERT=true"`). While this might be necessary in some enterprise environments, it weakens the security posture by disabling proper certificate validation. This makes the communication between the MCP server and the Veeam APIs vulnerable to Man-in-the-Middle (MITM) attacks, where an attacker could intercept and potentially modify sensitive data, including credentials or query results. Advise users to only enable `ACCEPT_SELF_SIGNED_CERT=true` in controlled environments where the risk is understood and mitigated. Ideally, recommend configuring proper certificate authorities (CAs) or using valid, trusted certificates for Veeam servers to ensure secure communication without disabling validation. | LLM | scripts/start-mcp.sh:26 | |
| MEDIUM | Excessive Permissions: Acceptance of Self-Signed Certificates The Docker container is configured to accept self-signed certificates (`-e "ACCEPT_SELF_SIGNED_CERT=true"`). While this might be necessary in some enterprise environments, it weakens the security posture by disabling proper certificate validation. This makes the communication between the MCP server and the Veeam APIs vulnerable to Man-in-the-Middle (MITM) attacks, where an attacker could intercept and potentially modify sensitive data, including credentials or query results. Advise users to only enable `ACCEPT_SELF_SIGNED_CERT=true` in controlled environments where the risk is understood and mitigated. Ideally, recommend configuring proper certificate authorities (CAs) or using valid, trusted certificates for Veeam servers to ensure secure communication without disabling validation. | LLM | scripts/test-connection.sh:30 | |
| LOW | Data Exfiltration/Credential Harvesting: Credentials via Environment Variables Sensitive credentials (URL, username, password) for Veeam servers are passed as environment variables to the 'veeam-intelligence-mcp-server' Docker container. While 'docker run --rm' helps prevent persistence, environment variables can sometimes be inspected from within the container or, in some scenarios, persist in process lists. The primary risk is if the 'veeam-intelligence-mcp-server' itself is compromised or malicious, it could exfiltrate these credentials. The skill's documentation states this is done 'securely', but it's a design choice with inherent risks compared to more robust secret management solutions. Consider alternative, more secure methods for secret management, such as Docker secrets, Kubernetes secrets, or mounting a temporary volume with the credentials, which might offer better isolation and auditing capabilities than environment variables. Ensure the 'veeam-intelligence-mcp-server' image is thoroughly vetted for security. | LLM | scripts/list-tools.sh:28 | |
| LOW | Data Exfiltration/Credential Harvesting: Credentials via Environment Variables Sensitive credentials (URL, username, password) for Veeam servers are passed as environment variables to the 'veeam-intelligence-mcp-server' Docker container. While 'docker run --rm' helps prevent persistence, environment variables can sometimes be inspected from within the container or, in some scenarios, persist in process lists. The primary risk is if the 'veeam-intelligence-mcp-server' itself is compromised or malicious, it could exfiltrate these credentials. The skill's documentation states this is done 'securely', but it's a design choice with inherent risks compared to more robust secret management solutions. Consider alternative, more secure methods for secret management, such as Docker secrets, Kubernetes secrets, or mounting a temporary volume with the credentials, which might offer better isolation and auditing capabilities than environment variables. Ensure the 'veeam-intelligence-mcp-server' image is thoroughly vetted for security. | LLM | scripts/query-veeam.sh:55 | |
| LOW | Data Exfiltration/Credential Harvesting: Credentials via Environment Variables Sensitive credentials (URL, username, password) for Veeam servers are passed as environment variables to the 'veeam-intelligence-mcp-server' Docker container. While 'docker run --rm' helps prevent persistence, environment variables can sometimes be inspected from within the container or, in some scenarios, persist in process lists. The primary risk is if the 'veeam-intelligence-mcp-server' itself is compromised or malicious, it could exfiltrate these credentials. The skill's documentation states this is done 'securely', but it's a design choice with inherent risks compared to more robust secret management solutions. Consider alternative, more secure methods for secret management, such as Docker secrets, Kubernetes secrets, or mounting a temporary volume with the credentials, which might offer better isolation and auditing capabilities than environment variables. Ensure the 'veeam-intelligence-mcp-server' image is thoroughly vetted for security. | LLM | scripts/start-mcp.sh:25 | |
| LOW | Data Exfiltration/Credential Harvesting: Credentials via Environment Variables Sensitive credentials (URL, username, password) for Veeam servers are passed as environment variables to the 'veeam-intelligence-mcp-server' Docker container. While 'docker run --rm' helps prevent persistence, environment variables can sometimes be inspected from within the container or, in some scenarios, persist in process lists. The primary risk is if the 'veeam-intelligence-mcp-server' itself is compromised or malicious, it could exfiltrate these credentials. The skill's documentation states this is done 'securely', but it's a design choice with inherent risks compared to more robust secret management solutions. Consider alternative, more secure methods for secret management, such as Docker secrets, Kubernetes secrets, or mounting a temporary volume with the credentials, which might offer better isolation and auditing capabilities than environment variables. Ensure the 'veeam-intelligence-mcp-server' image is thoroughly vetted for security. | LLM | scripts/test-connection.sh:29 |
Scan History
Embed Code
[](https://skillshield.io/report/b8dbc215430a5938)
Powered by SkillShield