Teslamate Deploy

• Outcome: Review
• Latest audit: Jul 10, 2026 · 12:08 AM UTC
• Version: 1.0.0

Overview

This appears to be a TeslaMate installer rather than malware, but it needs review because it makes broad server security changes and uses risky credential and image-source practices.

Install only on a dedicated Debian/Ubuntu host you are comfortable reconfiguring. Prefer SSH keys with verified host keys, avoid password SSH/sshpass, generate unique TeslaMate encryption and database secrets before exposing the service, restrict ports 3000/4000/1883 with a firewall or reverse proxy, back up existing Docker configuration first, and do not use the GitHub image fallback unless you independently trust that repository.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration

Findings (22)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 95% confidence
• Finding: The skill clearly instructs use of shell commands, SSH, Docker, and package installation, but no declared permissions are present. This creates a governance and review gap: a skill with remote execution capability can perform impactful actions without explicit permission scoping or user-visible authorization boundaries.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The documented purpose understates several security-sensitive behaviors: bypassing SSH host verification, supporting password-based SSH via sshpass, fetching images from GitHub as an alternate supply source, and relying on weak default secrets. This mismatch prevents informed consent and obscures material risk, especially because the skill performs remote deployment and credential-handling operations.

Intent-Code Divergence

Medium

• Confidence: 82% confidence
• Finding: The usage template claims the auth-setting flow will avoid shell history exposure, but the referenced helper script is not part of the declared bundled resources and the overall process still encourages handling high-value tokens interactively on remote systems. Users may assume the flow is safe when the actual storage, logging, or provenance of the script is unspecified.

Context-Inappropriate Capability

Medium

• Confidence: 98% confidence
• Finding: The script disables SSH host key verification for all remote connections by using StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null. This removes SSH's core identity validation and makes first and subsequent connections vulnerable to man-in-the-middle interception, which is especially dangerous because the script then uploads files and executes privileged commands on the remote host.

Context-Inappropriate Capability

Medium

• Confidence: 91% confidence
• Finding: The script changes system-wide networking and Docker daemon settings on the target host, including /etc/gai.conf, /etc/docker/daemon.json, and Docker service state. In a deployment skill, such broad host reconfiguration increases blast radius and can disrupt unrelated workloads or weaken the host's intended network/security posture beyond what is necessary to run TeslaMate.

Context-Inappropriate Capability

Medium

• Confidence: 97% confidence
• Finding: The script falls back to downloading container image tarball contents from an unrelated third-party GitHub repository and then loads them into Docker. Although it performs SHA256 checks against a manifest from the same remote source, that does not establish trust in the publisher; a compromised or malicious repository could supply arbitrary images that would run with the privileges and network access of the deployment.

Missing User Warnings

Medium

• Confidence: 99% confidence
• Finding: The pre-flight SSH commands disable StrictHostKeyChecking and in some cases discard known_hosts state, removing server identity verification. This exposes deployments and credentials to man-in-the-middle attacks, which is particularly dangerous because the skill performs remote installation and may later transmit passwords or execute privileged commands.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The skill directs users to export SSH passwords via an environment variable and use sshpass, which can expose credentials through process listings, shell history, logs, or inherited environments. In the context of remote administration, this is a sensitive credential-handling weakness that can lead to server compromise if the local machine or session is observed.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The uninstall section includes destructive commands (`docker compose down -v`, `docker image prune -a`, and `rm -rf`) that can permanently delete application data and local files. Although there is a brief warning sentence after the block, the affected command block itself does not force an immediate, prominent confirmation step, which increases the risk of accidental destructive execution in a deployment/troubleshooting skill.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The script performs extensive remote changes—package installation, daemon configuration, service enablement, file transfer, and privileged execution—without an explicit pre-execution warning or confirmation about scope. In an agent skill context, silent infrastructure modification is risky because users may not realize it will alter host-wide settings and persist services.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The script supports SSH password authentication via the SSH_PASS environment variable without warning users about credential exposure risks. Environment variables can leak through shell history, process inspection, CI logs, or debugging output, making this weaker than prompting securely or using SSH keys.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The script silently rewrites /etc/docker/daemon.json, appends to /etc/gai.conf, reloads systemd, and restarts Docker without prompting the user. In a deployment skill, these host-wide changes can disrupt existing containers, alter daemon behavior, and unexpectedly weaken or break local network configuration.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The script writes a local .env file containing hardcoded default secrets for the TeslaMate encryption key and database password. Default credentials are predictable and likely to be reused across installations, making compromise of the application data or connected services much easier if the deployment is exposed or the file is accessed.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The script downloads remote container artifacts and loads them into Docker without an explicit warning or trust confirmation. In this skill context, users expect automation for deployment, so silently introducing an alternate artifact supply path materially increases the chance that untrusted code is imported and executed.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

**Cause**: current user not in the `docker` group, script falls back to `sudo docker`.

**Fix**: if `sudo docker` itself fails, passwordless sudo isn't configured. Either:
- Add the user to `docker` group: `sudo usermod -aG docker $USER` (logout/login required)
- Or configure passwordless sudo: `echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/$USER`

• Confidence: 99% confidence
• Finding: This finding refers to the same `NOPASSWD:ALL` guidance, which effectively turns the specified user into a passwordless root-equivalent account. That is dangerous on any multi-user or internet-exposed server and is especially risky in an install/troubleshooting document that may be copied verbatim.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

**Cause**: current user not in the `docker` group, script falls back to `sudo docker`.

**Fix**: if `sudo docker` itself fails, passwordless sudo isn't configured. Either:
- Add the user to `docker` group: `sudo usermod -aG docker $USER` (logout/login required)
- Or configure passwordless sudo: `echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/$USER`

• Confidence: 99% confidence
• Finding: This finding refers to the same `NOPASSWD:ALL` guidance, which effectively turns the specified user into a passwordless root-equivalent account. That is dangerous on any multi-user or internet-exposed server and is especially risky in an install/troubleshooting document that may be copied verbatim.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

ssh ubuntu@RELAY_IP
sudo docker pull postgres:17                  # 32s on a CVM with internal mirror
sudo docker save postgres:17 -o /tmp/pg17.tar
sudo chmod 644 /tmp/pg17.tar                  # let non-sudo scp read it
exit

# On your Mac (the deploy machine)

• Confidence: 84% confidence
• Finding: Changing `/tmp/pg17.tar` to mode `644` makes the saved Docker image world-readable on the relay host. If the tarball contains proprietary, licensed, or premodified images, other local users on that host can read or copy it; in shared environments this weakens confidentiality unnecessarily.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

ssh ubuntu@RELAY_IP
sudo docker pull postgres:17                  # 32s on a CVM with internal mirror
sudo docker save postgres:17 -o /tmp/pg17.tar
sudo chmod 644 /tmp/pg17.tar                  # let non-sudo scp read it
exit

# On your Mac (the deploy machine)

• Confidence: 84% confidence
• Finding: Changing `/tmp/pg17.tar` to mode `644` makes the saved Docker image world-readable on the relay host. If the tarball contains proprietary, licensed, or premodified images, other local users on that host can read or copy it; in shared environments this weakens confidentiality unnecessarily.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

ssh ubuntu@RELAY_IP
sudo docker pull postgres:17                  # 32s on a CVM with internal mirror
sudo docker save postgres:17 -o /tmp/pg17.tar
sudo chmod 644 /tmp/pg17.tar                  # let non-sudo scp read it
exit

# On your Mac (the deploy machine)

• Confidence: 84% confidence
• Finding: Changing `/tmp/pg17.tar` to mode `644` makes the saved Docker image world-readable on the relay host. If the tarball contains proprietary, licensed, or premodified images, other local users on that host can read or copy it; in shared environments this weakens confidentiality unnecessarily.

Credential Access

High

• Category: Privilege Escalation

Content

echo "TM_API_KEY=$k" >> "$ENV_FILE"
   else
       echo "IMPORTANT: paste the REFRESH TOKEN (second block from tesla_auth),"
       echo "NOT the access token (which expires in 8h)."
       read -p "Paste Tesla REFRESH token: " t
       echo "TM_AUTH_TOKEN=$t" >> "$ENV_FILE"
   fi

• Confidence: 89% confidence
• Finding: The helper script reads the Tesla API key/refresh token via plain `read -p`, which echoes the secret on screen and can expose it to shoulder-surfing, terminal recording, or logging systems. In a deployment skill centered on handling live credentials, this is an avoidable secret-handling weakness.

Credential Access

High

• Category: Privilege Escalation

Content

mkdir -p import
    
    # 创建.env文件
    tee .env > /dev/null << ENV_CONFIG
TM_ENCRYPTION_KEY=${TM_ENCRYPTION_KEY}
TM_DB_PASS=${TM_DB_PASS}
ENV_CONFIG

• Confidence: 98% confidence
• Finding: The script creates a .env file containing secrets on disk, and those secrets are hardcoded predictable defaults. In this deployment context, the file becomes a sensitive local artifact that may be backed up, copied, or exposed through misconfiguration, leading to credential compromise and possible decryption of TeslaMate data.

Chaining Abuse

High

• Category: Tool Misuse

Content

**Fix**: if `sudo docker` itself fails, passwordless sudo isn't configured. Either:
- Add the user to `docker` group: `sudo usermod -aG docker $USER` (logout/login required)
- Or configure passwordless sudo: `echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/$USER`

### `docker compose version` returns "command not found"

• Confidence: 98% confidence
• Finding: Piping a constructed sudoers rule into `sudo tee /etc/sudoers.d/$USER` is a classic high-risk administrative chaining pattern because it creates persistent, unrestricted passwordless root access in one command. In an agent skill, this is especially dangerous because users may execute it verbatim without understanding that it permanently lowers host security.

Static analysis

No suspicious patterns detected.