Back to skill

Security audit

AI Cluster Pre-flight Check

Security checks for vulnerabilities and agentic risk

Overview

The skill is a real GPU-cluster checker, but it includes unsafe switch and container checks that deserve manual review before installation.

Review this skill before installing on production or privileged cluster nodes. Avoid using SWITCH_CLI_CMD unless the environment is fully trusted, prefer pinned and approved container images, require normal SSH host-key verification for switches, set MOUNT_POINT deliberately, and run the checks with the least privilege that still permits the diagnostics you need.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (4)

T09 · Insecure Skill Coding Practices

Error
Location
lib/checks.sh:327
Finding
Arbitrary Local Command Execution Through eval<![CDATA[ ## Vulnerability Details **File Location**: `lib/checks.sh:327-330` **Vulnerability Type**: OS command injection through unrestricted shell evaluation **Risk Level**: Critical ### Vulnerable Code ```bash check_1_25() { if [ -n "${SWITCH_CLI_CMD:-}" ]; then eval "$SWITCH_CLI_CMD" ``` ### Technical Analysis The `SWITCH_CLI_CMD` environment variable is passed directly to Bash's `eval` built-in. `eval` interprets the entire value as shell syntax, including command substitutions, redirections, pipelines, variable expansions, and compound commands. No validation, allowlist, escaping, or argument separation is applied. Consequently, any party able to influence the process environment can execute arbitrary local commands when check `1.25` is selected or included in the default check set. For example: ```bash SWITCH_CLI_CMD='id; cat ~/.ssh/id_rsa' \ PREFLIGHT_CHECKS=1.25 \ bash preflight.sh ``` The vulnerability is particularly severe when the Skill is launched by an automation system that constructs environment variables from user-controlled job parameters. ### Attack Path 1. An attacker gains control of, or injects content into, `SWITCH_CLI_CMD`. 2. A user, Agent, CI worker, or cluster automation service invokes check `1.25`. 3. `check_1_25` passes the environment value to `eval`. 4. Bash parses the attacker-controlled value as executable shell syntax. 5. The payload runs with all permissions and credentials available to the Skill process. ### Impact Assessment Successful exploitation provides arbitrary command execution with the privileges of the invoking account. If the health check is run as `root`, the attacker can obtain complete host control. Potential consequences include: - Reading SSH keys, tokens, configuration files, and other process-accessible secrets. - Modifying or deleting local and mounted filesystem content. - Altering cluster or network configuration. - Installing persistence or additional malicious software. - Pivoting ...[truncated 77 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Remove `eval` entirely. Do not expose an unrestricted shell command through an inherited environment variable. Recommended hardening measures: 1. Implement explicit vendor-specific switch adapters using fixed executable paths and fixed subcommands. 2. Represent command arguments as a Bash array so each argument remains a separate data value: ```bash cmd=(trusted-switch-cli --show-interface-status) "${cmd[@]}" ``` 3. If limited user selection is required, map a small allowlist of symbolic operation names to predefined commands. 4. Reject shell metacharacters, command substitutions, redirections, control characters, and unknown operation names. 5. Run switch checks under a dedicated, minimally privileged account with narrowly scoped credentials. 6. Avoid inheriting security-sensitive configuration from untrusted job or Agent environments. ]]>

T03 · Remote Payload Retrieval and Execution

Error
Location
lib/checks.sh:123
Finding
Mutable Remote Container Images Are Automatically Retrieved and Executed<![CDATA[ ## Vulnerability Details **File Location**: `lib/checks.sh:123-130` **Vulnerability Type**: Unverified remote payload retrieval and execution through mutable container tags **Risk Level**: High ### Vulnerable Code ```bash check_1_9() { local vendor vendor=$(_gpu_vendor) if [ "$vendor" = nvidia ]; then docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi --query-gpu=gpu_name --format=csv,noheader elif [ "$vendor" = amd ]; then docker run --rm --device /dev/kfd --device /dev/dri rocm/rocm-terminal rocm-smi --showproductname else ``` ### Technical Analysis The Skill executes container images identified only by mutable registry tags. The NVIDIA image has a version tag but is not pinned to an immutable content digest. The AMD image does not specify a version and therefore relies on the registry's default tag. When an image is not available locally, Docker can retrieve it automatically and immediately execute its entrypoint and command. The effective code being executed can therefore change after this Skill has been reviewed. The containers also receive direct access to GPU-related resources: - NVIDIA: `--gpus all` - AMD: `--device /dev/kfd --device /dev/dri` A compromised registry account, image namespace, publishing pipeline, or mutable tag could consequently introduce attacker-controlled code into the diagnostic process. ### Attack Path 1. A referenced registry account, publishing pipeline, or image tag is compromised or modified. 2. The host runs health check `1.9` without a previously trusted image available locally, or retrieves a newer tagged image. 3. Docker downloads the modified image. 4. Docker executes the image with network access and assigned GPU devices. 5. Malicious image code accesses available devices, network resources, and container-visible host information. ### Impact Assessment The immediate scope is code execution inside a container with access to the assigned GPU devices and Docker's ...[truncated 565 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin every image to an immutable SHA-256 digest: ```bash docker run --rm --gpus all \ nvidia/cuda@sha256:VERIFIED_DIGEST \ nvidia-smi --query-gpu=gpu_name --format=csv,noheader ``` 2. Verify image provenance and signatures before execution, such as through an approved image-signing and policy-enforcement system. 3. Prefer a controlled private registry with restricted publishing permissions. 4. Pre-pull and verify approved images during trusted provisioning rather than during a diagnostic run. 5. Use `--pull=never` after provisioning to prevent unexpected retrieval. 6. Disable container network access with `--network=none` where the diagnostic does not require networking. 7. Apply additional container restrictions, including capability removal, read-only filesystems, and security profiles, where compatible with GPU diagnostics. 8. Record approved digests in the Skill release so the executed dependency is reproducible and auditable. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
lib/checks.sh:327
Finding
SSH Host Identity Verification Is Disabled for Switch Connections<![CDATA[ ## Vulnerability Details **File Location**: `lib/checks.sh:327-333` **Vulnerability Type**: Insecure SSH configuration enabling machine-in-the-middle impersonation **Risk Level**: High ### Vulnerable Code ```bash check_1_25() { if [ -n "${SWITCH_CLI_CMD:-}" ]; then eval "$SWITCH_CLI_CMD" elif [ -n "${SWITCH_HOST:-}" ]; then ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 "${SWITCH_USER:-admin}@${SWITCH_HOST}" "${SWITCH_SHOW_CMD:-show interface status}" ``` ### Technical Analysis The switch SSH connection explicitly uses `StrictHostKeyChecking=no`. This permits an unknown host key to be accepted without prior trust establishment and weakens SSH's protection against machine-in-the-middle attacks. An attacker capable of manipulating DNS, routing, ARP resolution, or another part of the local network could impersonate the intended switch. The Skill would not require a pre-provisioned trusted switch key before establishing the connection. The remote command is intended to inspect switch state, so a spoofed endpoint can also return fabricated output and cause the health check to report misleading results. ### Attack Path 1. The operator configures `SWITCH_HOST` and runs check `1.25`. 2. An attacker redirects traffic for the switch address through DNS, routing, ARP spoofing, or another network-level technique. 3. The attacker presents an SSH key that is not pre-established as the trusted switch key. 4. The SSH client accepts the endpoint because strict host-key verification is disabled. 5. The attacker impersonates the switch and returns forged command output or observes authentication behavior. ### Impact Assessment Potential consequences include: - Loss of switch endpoint authenticity. - Fabrication of switch QoS or interface validation results. - Exposure of SSH authentication attempts to an unintended endpoint. - Presentation of Agent-backed or configured credentials to an attacker-controlled SSH server, depending on the invoking ...[truncated 254 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Require strict host-key verification: ```bash ssh \ -o StrictHostKeyChecking=yes \ -o UserKnownHostsFile=/etc/clusterready/switch_known_hosts \ -o ConnectTimeout=5 \ "${SWITCH_USER:-admin}@${SWITCH_HOST}" \ "${SWITCH_SHOW_CMD:-show interface status}" ``` 2. Provision and pin the expected switch host key through a trusted out-of-band process. 3. Use a dedicated `known_hosts` file with restrictive filesystem permissions. 4. Reject unknown or changed host keys rather than automatically accepting them. 5. Disable SSH agent forwarding and unnecessary authentication methods. 6. Use a dedicated switch account with read-only permissions limited to the required status commands. 7. Validate `SWITCH_HOST` and `SWITCH_USER` against an approved inventory. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
lib/checks.sh:11
Finding
Unvalidated Peer Values Can Be Interpreted as SSH Options<![CDATA[ ## Vulnerability Details **File Location**: `lib/checks.sh:11-18` **Vulnerability Type**: SSH argument injection through unvalidated environment input **Risk Level**: Medium ### Vulnerable Code ```bash local peers="${PREFLIGHT_PEER_IPS:-}" if [ -z "$peers" ]; then echo "skipped: PREFLIGHT_PEER_IPS not set (cross-node check)" >&2 return 3 fi local fail=0 IFS=',' read -ra ips <<< "$peers" for ip in "${ips[@]}"; do ip=$(echo "$ip" | xargs) if ssh -o BatchMode=yes -o ConnectTimeout=5 "$ip" echo ok 2>/dev/null; then ``` ### Technical Analysis `PREFLIGHT_PEER_IPS` is documented as a comma-separated collection of peer IP addresses, but each entry is passed to `ssh` without validation that it is actually an IPv4 address, IPv6 address, or approved hostname. Quoting the variable prevents ordinary shell metacharacter injection, but it does not ensure that the receiving program treats the value as a destination. A crafted value beginning with `-` may be interpreted by the SSH client as an option rather than as a hostname. Depending on the accepted option and client behavior, this can alter SSH configuration or introduce dangerous transport behavior such as a locally executed proxy command. The implementation also uses `xargs` for trimming, which is unnecessary and makes input normalization less predictable than explicit shell-based whitespace handling. ### Attack Path 1. An attacker controls or influences `PREFLIGHT_PEER_IPS` through an orchestration job, Agent request, wrapper script, or inherited environment. 2. The attacker supplies an entry beginning with an SSH option rather than a valid peer address. 3. Check `1.1` passes the crafted entry directly to `ssh`. 4. The SSH client interprets the value as configuration instead of a destination. 5. The attacker alters connection behavior and may reach a local command-execution primitive if a dangerous client option is accepted. ### Impact Assessment The obtainable scope depends ...[truncated 612 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Validate every peer entry before invoking SSH. 2. Accept only syntactically valid IPv4 addresses, IPv6 addresses, or hostnames matching a restrictive approved pattern. 3. Explicitly reject values that: - Begin with `-`. - Contain whitespace or control characters. - Contain shell or SSH configuration syntax. - Are not present in an approved cluster inventory. 4. Use a controlled SSH configuration file that disables unexpected features such as proxy commands. 5. Avoid relying on `xargs` for trimming; normalize whitespace with explicit, predictable shell logic. 6. Consider constructing a canonical destination such as a fixed account combined with a validated host. 7. Run peer checks under a minimally privileged account without broadly useful SSH credentials. ]]>
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (9)

Privileged Container / Container Escape

High
Category
Privilege Escalation
Content
if [ "$vendor" = nvidia ]; then
    docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi --query-gpu=gpu_name --format=csv,noheader
  elif [ "$vendor" = amd ]; then
    docker run --rm --device /dev/kfd --device /dev/dri rocm/rocm-terminal rocm-smi --showproductname
  else
    echo "No GPU vendor detected" >&2
    return 1
Confidence
70% confidence
Finding
Potential security issue detected. Manual review is recommended.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
done
  fi
  [ -z "$mp" ] && mp=/tmp
  df -h "$mp" && touch "$mp/.clusterready_test" && rm -f "$mp/.clusterready_test" && echo "read/write OK on $mp"
}

# 1.11  GPUDirect Kernel Module
Confidence
95% 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).

Chaining Abuse

High
Category
Tool Misuse
Content
done
  fi
  [ -z "$mp" ] && mp=/tmp
  df -h "$mp" && touch "$mp/.clusterready_test" && rm -f "$mp/.clusterready_test" && echo "read/write OK on $mp"
}

# 1.11  GPUDirect Kernel Module
Confidence
75% confidence
Finding
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Context-Inappropriate Capability

High
Confidence
99% confidence
Finding
The switch validation function executes the contents of SWITCH_CLI_CMD via 'eval', which allows arbitrary shell command execution if that environment variable is attacker-controlled or accidentally mis-set. Because this skill is intended for infrastructure pre-flight checks and may run with elevated privileges on cluster nodes, exploitation could lead to full local command execution on sensitive systems.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The skill documentation states that check 1.10 validates a shared mount with read/write access, but it does not clearly warn users that running the check may modify the target filesystem. On infrastructure skills, undocumented write behavior can cause unintended changes to production or shared storage, especially if operators assume the tool is read-only health validation.

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
89% confidence
Finding
The AMD container check uses 'rocm/rocm-terminal' without an explicit tag or digest, so each run may pull a different image over time. In a pre-flight check that may be executed on privileged cluster nodes, this creates avoidable supply-chain risk because behavior and contents of the image are not fixed.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The function can execute shell commands sourced from an environment variable, but there is no explicit warning, confirmation, or disclosure to the operator that arbitrary local commands may run. In practice this increases the chance of unsafe use, especially in automation pipelines where environment variables may come from CI, orchestration, or inherited shell state.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The SSH-based switch check disables host key verification with 'StrictHostKeyChecking=no', making the connection vulnerable to man-in-the-middle attacks or silent connection to an impostor host. In a cluster/network administration context, that is more dangerous because the command may query or trust data from infrastructure devices on privileged networks.

Static analysis

No suspicious patterns detected.