VPS Health Auditor

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:16 PM UTC
• Version: 1.0.0

Overview

The skill is a plausible VPS health checker, but it encourages root SSH access and ships an unsafe SSH script that can bypass host verification and mishandle user-supplied arguments.

Review this before installing or using it on real infrastructure. Use a dedicated low-privilege audit account and dedicated key, keep normal SSH host-key verification enabled, and do not pass untrusted host, user, or key values to the script unless it is hardened with quoting and validation.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/healthcheck.sh:6
• Finding: SSH Host-Key Verification Is Disabled## Vulnerability Details **File Location**: `scripts/healthcheck.sh`, line 6 **Vulnerability Type**: Improper SSH server authentication **Risk Level**: Medium ### Vulnerable Code ```bash ssh -i $KEY -o StrictHostKeyChecking=no $USER@$HOST << EOF ``` ### Technical Analysis The script explicitly sets `StrictHostKeyChecking=no`. This causes SSH to accept an unknown or changed server host key without requiring validation by the operator. SSH host-key verification establishes that the remote endpoint is the intended server. Disabling it allows a system controlling DNS resolution, network routing, or a network gateway to impersonate the target host. Although SSH public-key authentication does not directly disclose the private key, the client can authenticate to or interact with an unintended endpoint without warning. The behavior is not necessary for health auditing. A health-check tool can use the normal SSH trust model, a pre-provisioned `known_hosts` file, or carefully controlled trust-on-first-use behavior. ### Attack Path 1. A user invokes the health-check script for a remote VPS. 2. An attacker interferes with DNS resolution or network routing for the specified host. 3. The attacker presents an SSH host key that is not associated with the legitimate VPS. 4. `StrictHostKeyChecking=no` suppresses the host-identity validation failure. 5. The script connects to the attacker-controlled endpoint and runs the diagnostic command sequence against the wrong server. ### Impact Assessment An attacker can impersonate the audited server and cause the client to establish an SSH connection to an unintended host. This undermines the integrity and confidentiality of the audit session and can produce falsified health-check results. The vulnerability does not, by itself, reveal the contents of the client's private key or grant access to the legitimate server.
• Remediation: ## Remediation Suggestions - Remove `-o StrictHostKeyChecking=no`. - Use `StrictHostKeyChecking=yes` for pre-provisioned infrastructure. - Maintain a dedicated `known_hosts` file containing independently verified host keys. - If trust on first use is operationally required, use `StrictHostKeyChecking=accept-new`; this still rejects changed keys. - Consider specifying a dedicated known-hosts database: ```bash ssh \ -o StrictHostKeyChecking=yes \ -o UserKnownHostsFile="$HOME/.ssh/known_hosts" \ -i "$KEY" \ "$USER@$HOST" ``` - Document a secure process for verifying server fingerprints before the first audit.

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/healthcheck.sh:2
• Finding: Unquoted User-Controlled SSH Arguments Allow Option Injection## Vulnerability Details **File Location**: `scripts/healthcheck.sh`, lines 2–6 **Vulnerability Type**: Shell word splitting and SSH option injection **Risk Level**: High ### Vulnerable Code ```bash HOST=$1 USER=$2 KEY=$3 ssh -i $KEY -o StrictHostKeyChecking=no $USER@$HOST << EOF ``` ### Technical Analysis The script accepts the host, username, and private-key path as positional arguments and expands all three variables without quoting them. In Bash, unquoted variable expansion is subject to word splitting and pathname expansion. A malicious value containing whitespace can therefore become multiple arguments to `ssh`. The key parameter is particularly dangerous because it appears while SSH is still parsing options. A value constructed to contain an additional `-o` argument can inject SSH client configuration such as `ProxyCommand`. Since `ProxyCommand` can invoke a local process through a shell, successful option injection can lead to command execution on the machine running the Skill. Exploitation requires an attacker to control or influence the script arguments. Normal shell metacharacters embedded inside a variable are not automatically re-parsed as shell syntax by the current shell; the primary issue is creation of additional SSH arguments through word splitting, followed by dangerous interpretation by the SSH client. ### Attack Path 1. An attacker gains control over, or supplies, the key-path argument passed to `healthcheck.sh`. 2. The attacker includes whitespace followed by an additional SSH option in that argument. 3. The unquoted `$KEY` expansion is split into multiple command-line words. 4. `ssh` interprets the injected word as a client option rather than as part of the key filename. 5. If a dangerous option such as `ProxyCommand` is accepted, SSH invokes the attacker-selected local command. 6. The command executes with the operating-system privileges of the user running the Skill. ### Impact ...[truncated 560 chars]
• Remediation: ## Remediation Suggestions - Quote every parameter expansion. - Validate the username and hostname against strict allowlists. - Reject whitespace, control characters, leading hyphens, and unexpected delimiters. - Confirm that the key path resolves to an expected regular file with appropriately restrictive permissions. - Do not permit callers to inject arbitrary SSH client options. - Add strict error handling and argument-count validation. A hardened implementation should follow this pattern: ```bash #!/usr/bin/env bash set -euo pipefail if [[ $# -ne 3 ]]; then printf 'Usage: %s HOST USER KEY\n' "$0" >&2 exit 2 fi HOST=$1 USER=$2 KEY=$3 [[ $HOST =~ ^[A-Za-z0-9.-]+$ ]] || { echo "Invalid host" >&2 exit 2 } [[ $USER =~ ^[A-Za-z_][A-Za-z0-9_-]*$ ]] || { echo "Invalid user" >&2 exit 2 } [[ -f $KEY ]] || { echo "Invalid key file" >&2 exit 2 } ssh -i "$KEY" \ -o StrictHostKeyChecking=yes \ "$USER@$HOST" ``` Where practical, use a fixed SSH configuration alias rather than accepting raw connection components from untrusted input.

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:26
• Finding: Documentation Recommends Unnecessary Root SSH Access## Vulnerability Details **File Location**: `SKILL.md`, line 26 **Vulnerability Type**: Excessive privilege recommendation **Risk Level**: Medium ### Vulnerable Code ```text !vps-health-auditor --host example.com --user root --key ~/.ssh/id_rsa ``` ### Technical Analysis The Quick Start instructs users to connect directly as `root` using a general private key. The implemented diagnostics consist of resource queries and service-status checks: ```bash top -bn1 | head -20 free -h df -h ifconfig || ip addr uptime systemctl status ssh nginx mysql --no-pager || service --status-all | head -20 ``` These operations are read-only and generally do not require an unrestricted root login. Some service details may require elevated access on a particular distribution, but that does not justify granting the complete script a root SSH session. The documentation therefore exceeds the minimum privileges necessary for the declared health-audit functionality. It also recommends the default `~/.ssh/id_rsa`, which may be a broadly reusable identity rather than a dedicated, restricted audit key. The referenced command does not write to the private-key file. The SSH `-i` option reads the identity file. The risk is excessive access associated with the selected identity, not modification of SSH key material. ### Attack Path 1. An operator follows the documented Quick Start. 2. The operator supplies a private key authorized for unrestricted root login on the VPS. 3. The Skill establishes a root SSH session even though its checks are predominantly unprivileged and read-only. 4. A script flaw, unauthorized modification, or misuse of the audit workflow consequently operates within a root-capable access path. 5. The resulting compromise has administrative scope rather than being limited to a dedicated audit account. ### Impact Assessment The recommendation increases the impact of any compromise involving the script, its invoc ...[truncated 468 chars]
• Remediation: ## Remediation Suggestions - Replace the root example with a dedicated, unprivileged audit account. - Create a dedicated SSH key used only for health auditing rather than recommending the user's default private key. - Disable direct root SSH login where operationally possible. - Grant narrowly scoped `sudo` permissions only for individual commands that demonstrably require elevation. - Apply server-side SSH key restrictions such as source-address restrictions and a forced command where compatible with the workflow. - Document the minimum required permissions for every diagnostic. - Use a restricted example such as: ```text !vps-health-auditor --host example.com --user health-auditor --key ~/.ssh/vps_health_audit ``` - Ensure the dedicated account cannot modify services, system configuration, SSH settings, or unrelated application data.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Credential Access

High

• Category: Privilege Escalation

Content

## 🚀 Quick Start
```
!vps-health-auditor --host example.com --user root --key ~/.ssh/id_rsa
```

## Files

• Confidence: 96% confidence
• Finding: The quick-start example normalizes use of a root account with a direct private key path ('~/.ssh/id_rsa'), encouraging privileged access and unsafe credential handling patterns. In an agent skill context, this can lead users to expose sensitive key material, run diagnostics with unnecessary root privileges, and expand the blast radius if the skill or surrounding tooling mishandles the credential.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The description advertises SSH/local execution and diagnostics on remote hosts without a clear warning that the skill inspects systems and may run commands against local or remote infrastructure. Users may invoke it without understanding the scope of access, increasing the risk of unintended data exposure, intrusive host enumeration, or execution against sensitive systems.

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The skill auto-activates on broad substring matches like 'VPS health' or 'server check', which can trigger in unrelated conversations and cause an agent to propose or begin sensitive system-inspection actions unexpectedly. In the context of a skill that performs SSH/local execution and remote diagnostics, loose activation increases the chance of unauthorized or accidental operational actions.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The script disables SSH host key verification with `-o StrictHostKeyChecking=no`, which allows connections to proceed without validating the server's identity. This makes the healthcheck vulnerable to man-in-the-middle attacks, potentially exposing credentials, command output, and causing the script to run against an attacker-controlled host; in an infrastructure administration context, that elevates the practical risk beyond a routine warning.

Static analysis

No suspicious patterns detected.