Tencent Cloud Management Tool

• Outcome: Review
• Latest audit: Sep 12, 2026 · 7:34 AM UTC
• Version: 1.1.1

Overview

This Tencent Cloud management skill is mostly purpose-aligned, but it handles cloud credentials and privileged deployment steps in ways users should review carefully before installing.

Install only if you expect the agent to manage live Tencent Cloud resources. Use a least-privilege cloud account, require explicit confirmation for purchases, DNS changes, disk formatting, remote commands, and deletes, and avoid sending OAuth codes, SecretKeys, personal access tokens, or passwords through chat. Prefer SSH keys with host-key verification, pinned installers/images, and restrictive permissions for ~/.tccli credential files; rotate any credentials used with the documented insecure flows.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (5)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/lighthouse-app-deploy.md:235
• Finding: Mutable Remote Installation Scripts Executed Directly as Root<![CDATA[ ## Vulnerability Details **File Location**: `references/lighthouse-app-deploy.md:235-272` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash $SSH ' # Install Docker when the Docker CE image is not used curl -fsSL https://get.docker.com | sh systemctl enable docker && systemctl start docker # Pull and run the application docker run -d --name app --restart=always -p 80:8080 <image> ' ``` ```bash $SSH ' # Install Node.js through NodeSource curl -fsSL https://deb.nodesource.com/setup_20.x | bash - apt install -y nodejs cd /opt/app npm install npm run build ' ``` ### Technical Analysis The deployment guide downloads shell scripts from external URLs and pipes their contents directly into `sh` or `bash`. The effective scripts are mutable external payloads and are not included in the reviewed Skill package. No version pinning, detached-signature verification, checksum verification, or local inspection is performed before execution. These commands run through the guide's root SSH session, so every instruction returned by either endpoint receives unrestricted operating-system privileges. The domains appear related to the declared Docker and Node.js installation tasks, and there is no evidence that the current endpoints are intentionally malicious. Nevertheless, this delivery pattern allows the effective behavior to change after Skill review and therefore constitutes a remote payload execution vulnerability. ### Attack Path 1. A user asks the agent to deploy a Docker or Node.js application. 2. The Skill directs the agent to follow `references/lighthouse-app-deploy.md`. 3. The agent establishes a remote SSH session as `root`. 4. The agent retrieves a mutable installation script from `get.docker.com` or `deb.nodesource.com`. 5. The downloaded bytes are immediately passed to a privileged shell without integrity validation. 6. If the upstream service, distribution infrastructure, DNS resolu ...[truncated 861 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove all `curl | sh` and `curl | bash` installation patterns. 2. Prefer distribution-maintained packages from explicitly configured, authenticated repositories. 3. If a vendor installer is unavoidable: - Pin an immutable installer version or commit. - Download it to a local file without executing it. - Verify a hard-coded cryptographic checksum or an official detached signature. - Review the downloaded script before execution. - Execute it only after explicit user confirmation. 4. Run installation with the minimum privileges required rather than placing the entire deployment session under `root`. 5. Record the verified artifact version and expected digest in the Skill documentation. 6. Prefer a prebuilt, trusted Docker CE image when Docker is required. 7. For Node.js, use a signed repository configuration or a version manager with verified release artifacts rather than executing a repository setup script directly. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: references/lighthouse-app-deploy.md:184
• Finding: SSH Host Verification Disabled and Root Password Exposed in Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `references/lighthouse-app-deploy.md:184-185` **Vulnerability Type**: Insecure SSH authentication and secret handling **Risk Level**: High ### Vulnerable Code ```bash SSH="sshpass -p '<password>' ssh -o StrictHostKeyChecking=no root@<public-ip>" SCP="sshpass -p '<password>' scp -o StrictHostKeyChecking=no" ``` ### Technical Analysis `StrictHostKeyChecking=no` suppresses SSH server-identity validation. On an initial connection, the client accepts an arbitrary host key instead of requiring the target instance's expected fingerprint. This defeats SSH's protection against active machine-in-the-middle attacks. The use of `sshpass -p` also places the root password in a command-line argument and shell variable. Depending on operating-system behavior and execution tooling, command arguments may be exposed through process inspection, shell history, agent logs, diagnostic output, or monitoring systems. Using a reusable password for direct root access further exceeds the minimum privilege needed for routine application deployment. A restricted deployment account with narrowly scoped privilege escalation would materially reduce impact. ### Attack Path 1. The agent stores the Lighthouse root password in the `SSH` and `SCP` shell variables. 2. The agent initiates its first SSH connection without possessing a trusted host key. 3. A network-positioned attacker redirects or intercepts the connection and presents an attacker-controlled SSH host key. 4. Because strict host-key checking is disabled, the client accepts the impersonated server. 5. The password is submitted to the attacker's SSH endpoint, or source archives are uploaded to it. 6. The attacker reuses the captured root password against the real instance. 7. Alternatively, another local user or process-monitoring component obtains the password from the process command line or execution logs. ### Impact Assessment An attacker who captures the password can o ...[truncated 501 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `StrictHostKeyChecking=no`. 2. Obtain the instance's SSH host-key fingerprint through a trusted channel and add it to a dedicated `known_hosts` file before connecting. 3. Use `StrictHostKeyChecking=yes` and fail closed on any host-key mismatch. 4. Replace password authentication with a short-lived or user-specific SSH key. 5. Do not pass secrets with `sshpass -p` or place them in shell variables and command arguments. 6. Disable direct root SSH login and use a dedicated deployment user. 7. Grant that user only the specific `sudo` operations required for package installation and service management. 8. Ensure agent logs, command traces, and shell history never include credentials. 9. Rotate any password that may already have been used through this workflow. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/tccli-oauth-helper.py:208
• Finding: OAuth Authentication Continues After State Validation Failure<![CDATA[ ## Vulnerability Details **File Location**: `scripts/tccli-oauth-helper.py:208-214` **Vulnerability Type**: OAuth state validation bypass **Risk Level**: High ### Vulnerable Code ```python # Validate state when saved state is available token_state = token.get("state") if saved_state and token_state != saved_state: print(f"Warning: state mismatch") print(f" Expected: {saved_state}") print(f" Actual: {token_state}") print() print("An old authorization URL may have been used. Continuing...") ``` ### Technical Analysis OAuth `state` binds an authorization response to the authorization request initiated by the local client. A mismatch must terminate authentication. The helper detects a mismatch but deliberately continues. It subsequently calls `get_temp_cred()` with the access token from the supplied Base64 object and saves the returned credentials to the selected tccli profile. Consequently, state validation provides no enforcement when a saved state exists. The helper also continues when no saved state is available, including cases where the state file has expired. This permits an independently obtained authorization result to be processed without proving that it belongs to the current local login attempt. ### Attack Path 1. A victim or agent starts an OAuth login, causing the helper to save an expected state. 2. An attacker obtains a valid Base64 authorization result from a different OAuth flow or convinces the victim to submit such a value. 3. The helper decodes the supplied token and detects that its state differs from the saved state. 4. Instead of aborting, the helper prints a warning and continues. 5. It sends the supplied access token to Tencent Cloud's temporary-credential endpoint. 6. It writes the returned credentials into the requested local tccli profile. 7. The local CLI now operates under an unintended account or authorization context, creating account-confusion and login-CSRF conditions. ### Impact Assessm ...[truncated 578 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Immediately abort authentication when `saved_state` is absent, expired, or different from `token_state`. 2. Clear stale state and require the user to begin a fresh authorization flow. 3. Compare state values with `hmac.compare_digest`. 4. Require the decoded token to contain all expected fields and validate their types before any network request. 5. Bind the authorization flow to the intended profile and prevent silent replacement of an existing profile. 6. Ask for explicit confirmation before overwriting an existing credential file. 7. Add tests proving that missing, expired, malformed, and mismatched state values cannot reach `get_temp_cred()` or `save_credential()`. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/tccli-oauth-helper.py:104
• Finding: OAuth State Generated with a Non-Cryptographic Random Number Generator<![CDATA[ ## Vulnerability Details **File Location**: `scripts/tccli-oauth-helper.py:104-107` **Vulnerability Type**: Predictable security token generation **Risk Level**: Medium ### Vulnerable Code ```python def generate_state(): """Generate random state.""" characters = string.ascii_letters + string.digits return ''.join(random.choice(characters) for _ in range(10)) ``` ### Technical Analysis Python's `random` module uses a deterministic pseudorandom number generator and is not designed for authentication tokens. Its output can become predictable if an attacker can infer or recover generator state. The generated value is also only ten alphanumeric characters, which is shorter than customary high-entropy OAuth state tokens. OAuth state is a security-sensitive nonce used to prevent login CSRF and response substitution. Its unpredictability is therefore a security requirement. This weakness compounds the separate failure to enforce state mismatches. ### Attack Path 1. The helper generates OAuth state using Python's process-global `random` generator. 2. An attacker observes enough related output or otherwise infers the generator state in a plausible shared-process environment. 3. The attacker predicts a future OAuth state value. 4. The attacker prepares or substitutes an authorization result using the predicted value. 5. If accepted by the surrounding authorization flow, the attacker can interfere with account binding or cause an unintended identity to be installed. 6. The existing mismatch-tolerant behavior further reduces the protection supplied by state. ### Impact Assessment By itself, predictable state weakens OAuth login-CSRF protection and authorization-response binding. When combined with permissive state handling, it increases the likelihood of account confusion and unauthorized tccli profile replacement. The resulting cloud privileges are limited to those represented by the substituted OAuth authorization, but subsequent agent act ...[truncated 62 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace the generator with a cryptographically secure token: ```python import secrets def generate_state(): return secrets.token_urlsafe(32) ``` 2. Use at least 128 bits of entropy. 3. Keep the state single-use and enforce the existing ten-minute expiration. 4. Delete the state after either successful validation or a failed/mismatched callback. 5. Pair secure generation with strict, constant-time state validation. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/tccli-oauth-helper.py:65
• Finding: Cloud Credential File Is Written Without Explicit Restrictive Permissions<![CDATA[ ## Vulnerability Details **File Location**: `scripts/tccli-oauth-helper.py:65-83` **Vulnerability Type**: Insecure storage of plaintext cloud credentials **Risk Level**: High ### Vulnerable Code ```python def save_credential(token, new_cred, profile): """Save credentials.""" cred_path = cred_path_of_profile(profile) # Ensure directory exists os.makedirs(os.path.dirname(cred_path), exist_ok=True) cred = { "type": "oauth", "secretId": new_cred["secretId"], "secretKey": new_cred["secretKey"], "token": new_cred["token"], "expiresAt": new_cred["expiresAt"], "oauth": { "openId": token["openId"], "accessToken": token["accessToken"], "expiresAt": token["expiresAt"], "refreshToken": token["refreshToken"], "site": token["site"], }, } with open(cred_path, "w") as cred_file: json.dump(cred, cred_file, indent=4) ``` ### Technical Analysis The credential file contains a SecretId, SecretKey, session token, OAuth access token, and refresh token. It is created with ordinary `open(..., "w")`, so its permissions depend on the process umask and any pre-existing file mode. The parent directory is also created without an explicit restrictive mode. The code does not verify ownership, reject symbolic links, enforce mode `0600`, or use an atomic create-and-replace operation. On a shared or permissively configured system, this may expose active cloud credentials to other local users. An attacker who can manipulate the path may also attempt a symlink-based overwrite or redirection attack. The OAuth state file is written using the same general pattern elsewhere in the script, although the credential file presents the more severe exposure because it contains reusable authentication material. ### Attack Path 1. The helper runs on a shared host or under an account with a permissive umask, or the credential file already ha ...[truncated 1134 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Create `~/.tccli` with mode `0700` and verify that it is owned by the current user. 2. Create credential and state files with mode `0600`, independent of the process umask. 3. Use `os.open()` with `O_CREAT | O_EXCL | O_WRONLY` and mode `0o600`, or write atomically to a securely created temporary file before replacing the destination. 4. Reject symbolic links and validate the destination with `lstat()` before writing. 5. Apply `os.chmod(path, 0o600)` to safely handled existing files and fail if ownership is unexpected. 6. Avoid retaining refresh tokens unless automatic refresh is essential to the declared workflow. 7. Store credentials in an operating-system keyring or dedicated secret manager where available. 8. Never print credential values, and prevent backup, telemetry, or diagnostic tools from collecting the credential directory. 9. Revoke and regenerate credentials if a file was previously accessible to unintended users. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (35)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The skill is presented as a Tencent Cloud resource-management tool, but it also handles authentication bootstrapping, credential-status checks, and local credential storage management. That mismatch is dangerous because users may consent to cloud operations without realizing the skill can facilitate account login flows and modify persistent local auth material.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The document recommends `sshpass` with a plaintext password and `StrictHostKeyChecking=no`, which both exposes credentials locally and disables server authenticity verification. In this deployment context, that combination materially increases the chance of credential theft and man-in-the-middle compromise during administrative access to newly created cloud servers.

Credential Access

High

• Category: Privilege Escalation

Content

'
```

> 私有仓库需配置 SSH Key 或使用 Personal Access Token：
> `git clone https://<token>@github.com/<user>/<repo>.git`

---

• Confidence: 97% confidence
• Finding: The explicit recommendation to use a Personal Access Token in the clone URL exposes a reusable credential during deployment operations. In practice, this can lead to unauthorized repository access, source disclosure, or lateral movement into associated development systems if the token is overscoped.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: Embedding a Personal Access Token directly in a Git URL can leak the token via shell history, process listings, logs, CI output, or remote tooling. Because this skill is for provisioning and deployment, such leaked tokens may grant access to private repositories and possibly broader source-code or CI/CD resources.

Chaining Abuse

High

• Category: Tool Misuse

Content

```bash
$SSH '
# 安装 Docker（如非 Docker CE 镜像）
curl -fsSL https://get.docker.com | sh
systemctl enable docker && systemctl start docker

# 拉取并运行

• Confidence: 96% confidence
• Finding: The `| sh` chaining pattern is dangerous here because it turns an untrusted network response directly into shell execution as root over SSH. In a deployment skill, this creates a straightforward remote code execution path if the upstream content, transport, or endpoint trust is compromised.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

$SSH '
# 安装 Go
wget -q https://go.dev/dl/go1.22.5.linux-amd64.tar.gz -O /tmp/go.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf /tmp/go.tar.gz
export PATH=$PATH:/usr/local/go/bin

# 构建

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

$SSH '
# 安装 Go
wget -q https://go.dev/dl/go1.22.5.linux-amd64.tar.gz -O /tmp/go.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf /tmp/go.tar.gz
export PATH=$PATH:/usr/local/go/bin

# 构建

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

EOF

ln -sf /etc/nginx/sites-available/app /etc/nginx/sites-enabled/
rm -f /etc/nginx/sites-enabled/default
nginx -t && systemctl restart nginx

# 申请 SSL 证书（需域名已解析到此 IP）

• Confidence: 85% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The script encourages sharing the OAuth verification code but does not warn that it contains sensitive authentication data. In this skill context, users are managing Tencent Cloud resources, so disclosure can lead to unauthorized cloud access, privilege abuse, or resource manipulation.

Ssd 3

High

• Confidence: 99% confidence
• Finding: Telling users to provide the verification code to an AI assistant encourages disclosure of authentication material through conversational channels that may be logged, retained, or exposed. Because the code can be used to obtain cloud credentials, this materially increases the attack surface and risk of account compromise.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 88% confidence
• Finding: The skill performs network access, reads reference files, and writes local credential state, but it does not declare any explicit tool scope or allowed-tools boundary. In a cloud-management skill that can touch authentication flows and local config, missing capability scoping increases the risk of unintended tool use or privilege expansion beyond what users expect.

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The trigger phrases are broad and overlap with common requests like checking servers, deploying apps, switching accounts, and security checks, making accidental invocation more likely. In this context, overbroad activation is risky because the skill can lead users into authentication and cloud-management operations that affect live infrastructure and local credentials.

Ssd 3

Medium

• Confidence: 95% confidence
• Finding: The skill explicitly tells the user to send the OAuth verification code to the AI assistant, which places sensitive authentication material into the model conversation channel in plain text. Even if the code is short-lived, exposing it to the assistant creates avoidable account-access risk, expands the number of systems handling the secret, and normalizes unsafe credential-sharing behavior.

Vague Triggers

Medium

• Confidence: 84% confidence
• Finding: The applicability guidance uses broad scenario descriptions that blur the boundary between health diagnosis, general resource inspection, and other cloud-management actions. In this context, an ambiguous match is dangerous because the skill contains discovery logic for tags, resources, and monitoring namespaces, so accidental activation can expand the scope of data accessed beyond what the user clearly requested.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The trigger examples for invoking the health-check workflow include broad natural-language requests such as service inspection and diagnosis, which can overlap with other operational or security tasks. In an agent skill that can enumerate cloud resources and pull monitoring data, ambiguous activation can cause the wrong workflow to run, leading to unintended account-wide discovery, privacy exposure, or user confusion about what checks are being performed.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The trigger list includes broad phrases such as ‘安全检查’, ‘安全审计’, and ‘安全评估’, which can match many ordinary cloud-management requests and cause this skill to activate unexpectedly. In this skill’s context, unexpected activation is risky because the workflow mandates broad enumeration of security groups, instances, monitoring policies, and CAM users/keys, potentially leading to over-collection of sensitive account security data beyond the user’s actual intent.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The guide instructs users to export cloud API credentials as plaintext environment variables without any warning about shell history, process inspection, accidental logging, or persistence in terminal sessions. In a cloud administration skill, exposing long-lived credentials can directly enable unauthorized resource access, modification, or account compromise.

Session Persistence

Medium

• Category: Rogue Agent

Content

$SSH '
# 安装 Docker（如非 Docker CE 镜像）
curl -fsSL https://get.docker.com | sh
systemctl enable docker && systemctl start docker

# 拉取并运行
docker run -d --name app --restart=always -p 80:8080 <image>

• Confidence: 80% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Session Persistence

Medium

• Category: Rogue Agent

Content

$SSH '
# 安装 Docker（如非 Docker CE 镜像）
curl -fsSL https://get.docker.com | sh
systemctl enable docker && systemctl start docker

# 拉取并运行
docker run -d --name app --restart=always -p 80:8080 <image>

• Confidence: 80% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

External Transmission

Medium

• Category: Data Exfiltration

Content

$SSH 'systemctl status app --no-pager'

# HTTP 验证
curl -s -o /dev/null -w "HTTP %{http_code}\n" http://<公网IP>/

# 浏览器访问
http://<公网IP>

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The guide provides direct commands and an automation flow that create Lighthouse instances, purchase domains, and publish DNS records, but it does not include an explicit user-facing warning that these actions incur cost and make services publicly reachable. In an agent skill context, this increases the risk of unintended purchases or exposure if an agent follows the playbook too eagerly or with ambiguous user authorization.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The instructions use TAT to execute a remote command and then decode and print the Baota panel's initial password, exposing sensitive credentials in terminal output, logs, transcripts, or agent memory. Because the same guide also discusses opening and accessing the management panel, credential disclosure could quickly enable unauthorized administrative access if outputs are observed or retained.

Static analysis

Detected: suspicious.destructive_delete_command

Documentation contains a destructive delete command without an explicit confirmation gate.

Warn

• Code: suspicious.destructive_delete_command
• Location: references/lighthouse-app-deploy.md:257