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

Content

View full analysis

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

View 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

Content

View full analysis

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

View 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

Content

View full analysis

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

View 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
• 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.

Content

Scanner excerpt · SKILL.md (reported line 26)May include surrounding context.

🚀 Quick Start

text

!vps-health-auditor --host example.com --user root --key ~/.ssh/id_rsa

Files

Missing User Warnings

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.