aleph-cloud-self-deployment

• Outcome: Review
• Latest audit: Sep 11, 2026 · 12:09 PM UTC
• Version: 1.0.2004

Overview

This skill is openly for autonomous cloud self-cloning, but its examples give spawned VMs broad paid-account credentials and use unsafe setup and secret-handling patterns.

Review before installing. Use only in an isolated test account or VM, set hard spending and instance limits outside the agent, require human approval for provisioning, use delegated per-child Aleph keys instead of copying the parent key, verify SSH host keys, pin and verify dependencies, and avoid placing API keys or wallet keys in command-line arguments or logs.

A.I.G

Vulnerability Patterns

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

Findings (5)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:261
• Finding: Remote setup script is downloaded and executed directly as root<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:261` and `SKILL.md:553` **Vulnerability Type**: Remote code retrieval and immediate shell execution **Risk Level**: Critical ```bash # Install Node.js 22 curl -fsSL https://deb.nodesource.com/setup_22.x | bash - DEBIAN_FRONTEND=noninteractive apt-get install -y nodejs git ``` The same vulnerable installation pattern appears in the post-creation setup script: ```bash echo "=== Installing Node.js 22 ===" curl -fsSL https://deb.nodesource.com/setup_22.x | bash - DEBIAN_FRONTEND=noninteractive apt-get install -y nodejs git python3-pip ``` ### Technical Analysis The commands download a mutable response from `https://deb.nodesource.com/setup_22.x` and pass it directly to a privileged shell. There is no content hash, detached signature, pinned artifact, or review step between retrieval and execution. NodeSource is a recognizable external provider, and installing Node.js is necessary for the declared OpenClaw deployment workflow. However, immediate root execution of mutable network content is not the minimum privilege or minimum trust mechanism required to install Node.js. Because the script runs while provisioning a root-operated VM, any code returned by the endpoint receives unrestricted system privileges. The effective payload can also change after the Skill has been reviewed. ### Attack Path 1. An attacker compromises the remote endpoint, its hosting infrastructure, DNS resolution, or another trusted component in the HTTPS delivery chain. 2. The attacker modifies the response returned for `setup_22.x`. 3. A user or autonomous agent follows the deployment instructions. 4. `bash` executes the attacker-controlled response immediately as root. 5. The payload installs persistence, modifies packages, or waits for API keys and Aleph credentials to be placed on the VM. 6. The attacker gains control over the deployed agent and any credentials subsequently transferred to it. ### Impact Assessment Succe ...[truncated 322 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not pipe network responses directly into a shell. - Prefer distribution-provided, signed Node.js packages where practical. - If NodeSource is required, download the setup artifact separately and verify a vendor-published cryptographic signature or independently obtained digest before execution. - Pin the repository configuration, signing-key fingerprint, Node.js major/minor version, and package version. - Execute installation in a clean provisioning environment before placing application secrets on the VM. - Retain an auditable copy or digest of the reviewed setup artifact. ]]>

T08 · Insecure Dependencies

Error

• Location: SKILL.md:24
• Finding: Unpinned dependencies are installed with system-wide root privileges<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:24`, `SKILL.md:220`, `SKILL.md:265`, `SKILL.md:405`, `SKILL.md:557`, and `SKILL.md:560` **Vulnerability Type**: Unpinned privileged dependency installation **Risk Level**: High ```bash pip install aleph-client --break-system-packages ``` ```bash Install pexpect: `pip install pexpect --break-system-packages` ``` ```bash # Install OpenClaw npm install -g openclaw ``` The child-VM and setup instructions repeat the same patterns: ```bash pip install aleph-client --break-system-packages ``` ```bash echo "=== Installing OpenClaw ===" npm install -g openclaw echo "=== Installing aleph-client ===" pip install aleph-client --break-system-packages ``` ### Technical Analysis The Skill installs `aleph-client`, `pexpect`, and `openclaw` without exact version constraints or verified artifact hashes. Transitive dependencies are also unresolved and unpinned. The `--break-system-packages` option intentionally permits pip to modify the system Python environment. The global npm installation is performed in a root provisioning context and may execute package lifecycle scripts with root privileges. Installing these applications is relevant to the declared deployment functionality, but unrestricted installation of the latest registry versions exceeds the trust and privilege needed for a reproducible deployment. This is primarily a supply-chain risk rather than evidence that the named packages are currently malicious. ### Attack Path 1. An attacker compromises the publisher account or a direct or transitive dependency. 2. The attacker publishes a malicious version that satisfies the unconstrained package request. 3. A later deployment resolves the new package from PyPI or npm. 4. Package installation or lifecycle code runs with system-wide privileges. 5. The malicious code modifies the VM, captures credentials, or replaces the installed agent tooling. ### Impact Assessment Exploitation can result in root-le ...[truncated 254 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin exact reviewed versions of all direct dependencies. - Lock and review transitive dependencies. - Use `pip --require-hashes` with a hash-pinned requirements file. - Install Python dependencies in a dedicated virtual environment instead of using `--break-system-packages`. - Use an npm lockfile, verified package tarball, or controlled internal registry rather than an unconstrained global installation. - Disable unnecessary npm lifecycle scripts or review required scripts before privileged installation. - Run application components under a dedicated unprivileged service account after installation. - Add automated dependency vulnerability and provenance checks to the deployment process. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:252
• Finding: SSH host authenticity verification is disabled for privileged connections and file transfers<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:252`, `SKILL.md:377`, and `SKILL.md:388` **Vulnerability Type**: SSH host-key verification bypass **Risk Level**: High ```bash # Connect ssh -o StrictHostKeyChecking=no root@<HOST_IP> -p <MAPPED_PORT> -i ~/.ssh/aleph_agent ``` ```bash HOST="<HOST_IP>" PORT="<MAPPED_PORT>" KEY="$HOME/.ssh/aleph_agent" SCP="scp -i $KEY -P $PORT -o StrictHostKeyChecking=no" ``` ```bash # Skills directory (recursive) scp -r -i $KEY -P $PORT -o StrictHostKeyChecking=no /root/openclaw/skills/ root@$HOST:/root/openclaw/skills/ ``` ### Technical Analysis `StrictHostKeyChecking=no` instructs SSH and SCP to accept an unverified server host key. This removes the mechanism that authenticates the destination VM before a root session is established or sensitive files are copied. Initial connection automation may require provisioning a new host key, but completely disabling verification is broader than necessary. The Skill transfers identity files, memory, Skills, and potentially deployment-related material through these connections. ### Attack Path 1. An attacker gains a network interception position or causes the operator to use a substituted host address or mapped port. 2. The attacker presents an arbitrary SSH host key. 3. Because strict verification is disabled, the client accepts the impersonating server. 4. Identity, memory, and Skill files are copied to the attacker-controlled endpoint. 5. The attacker may return modified content, deceive the operator into transferring additional credentials, or interfere with deployment. ### Impact Assessment The immediate scope includes disclosure of copied OpenClaw identity, memory, and Skill content and loss of destination integrity. If the same unverified channel is used for later private-key or credential operations, the compromise can expand to control of the agent and funded cloud account. The SSH client key itself is not normally disclosed by the SSH protocol, but server ...[truncated 71 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Keep strict host-key checking enabled. - Retrieve the VM host-key fingerprint through an authenticated Aleph API or another independent trusted channel. - Populate a deployment-specific `known_hosts` file before connecting. - Use `UserKnownHostsFile` to isolate ephemeral deployment hosts without disabling verification. - Abort the deployment if the advertised fingerprint cannot be independently verified. - Apply the same verified SSH configuration to every SSH and SCP command. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:412
• Finding: Parent account private key is duplicated to autonomous child agents<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:412-420` **Vulnerability Type**: Excessive delegation of funded-account authority **Risk Level**: Critical ```bash ### Transfer Aleph Private Key ```bash # SENSITIVE — never log this key $SCP /root/.aleph-im/private-keys/your-key.key root@$HOST:/root/.aleph-im/private-keys/your-key.key ssh -i $KEY -p $PORT root@$HOST "chmod 700 /root/.aleph-im/private-keys && chmod 600 /root/.aleph-im/private-keys/*.key" # Activate on the child ssh -i $KEY -p $PORT root@$HOST "aleph account create --private-key \$(cat /root/.aleph-im/private-keys/your-key.key) --chain BASE --active" ``` ### Technical Analysis The Skill copies the parent Aleph private key to a remote VM and activates it for use by the child agent. File permissions of `600` reduce access by other local users, but they do not limit the authority available to the root-operated agent, OpenClaw components, or an attacker who compromises the VM. Self-deployment requires some authorization to provision instances, so credential access is related to the declared functionality. However, duplicating the unrestricted parent key is not least privilege. It gives every child the same funded-account authority as the parent and enables recursive proliferation. The document acknowledges this risk and recommends delegated keys for production, but its executable example still performs the unsafe transfer. The separate access to `~/.ssh/aleph_agent` is functionally necessary for administering the created VM. The principal privilege violation is the transfer of the funded Aleph account key, not merely referencing the dedicated SSH key. ### Attack Path 1. The parent deploys a child VM and copies its Aleph private key to that VM. 2. The child agent, a compromised dependency, or an attacker with root access reads the key. 3. The key is used to authorize additional paid instance deployments. 4. New children receive equivalent deployment authority or attacker-controll ...[truncated 658 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Never copy the parent account private key to child VMs. - Generate a unique delegated credential for each child. - Apply the minimum available permissions, a small isolated balance, deployment quotas, expiration, and revocation capability. - Enforce maximum instance counts and spending limits outside the agent-controlled environment. - Require explicit human approval before production provisioning, as already recommended by the Skill's security section. - Store deployment credentials in a managed secret or signing service so raw private-key material is not present on child disks. - Rotate and revoke credentials immediately if a child VM is destroyed or suspected of compromise. - Maintain an inventory mapping every delegated key to its VM, limits, and expiration. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:463
• Finding: API and gateway secrets may be exposed through process arguments and deployment logs<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:463-477`, `SKILL.md:308`, and `SKILL.md:605-609` **Vulnerability Type**: Insecure secret input and output handling **Risk Level**: Medium ```bash #!/bin/bash # deploy.sh — Create a new Aleph Cloud agent clone # Usage: ./deploy.sh [name] [compute-units] [anthropic-key] set -euo pipefail AGENT_NAME="${1:-agent-$(date +%s)}" COMPUTE_UNITS="${2:-1}" ANTHROPIC_KEY="${3:-$ANTHROPIC_API_KEY}" SSH_KEY="$HOME/.ssh/aleph_agent" ROOTFS="5330dcefe1857bcd97b7b7f24d1420a7d46232d53f27be280c8a7071d88bd84e" ROOTFS_SIZE=40960 if [ -z "$ANTHROPIC_KEY" ]; then echo "ERROR: Set ANTHROPIC_API_KEY env var or pass as 3rd arg" exit 1 fi ``` ```bash GATEWAY_TOKEN=$(openssl rand -hex 24) echo "Gateway token: $GATEWAY_TOKEN" # Save this! ``` ```bash echo "" echo "=== SETUP COMPLETE ===" echo "Gateway token: $GATEWAY_TOKEN" echo "OpenClaw: $(openclaw --version)" echo "Node: $(node --version)" ``` ### Technical Analysis The deployment script explicitly supports passing the Anthropic API key as the third positional command-line argument. Command-line secrets can be retained in shell history and may be visible to process-monitoring tools or other sufficiently privileged local users while the process runs. The gateway token is printed to standard output in both the manual configuration and setup script. Deployment output is commonly captured by terminal recorders, CI systems, orchestration logs, or support bundles. Although the token is randomly generated and the gateway binds to loopback by default, disclosure may become exploitable through local access, SSH forwarding, or later gateway exposure. The script validates `ANTHROPIC_KEY` but the shown post-creation setup segment does not write it into `auth-profiles.json`; this does not remove the exposure caused by accepting it as an argument. ### Attack Path 1. An operator invokes the deployment script with the Anthropic key as a positional argument. 2. The key is ...[truncated 807 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove support for API keys as positional command-line arguments. - Read secrets from a protected file descriptor, interactive no-echo prompt, or managed secret service. - Avoid placing long-lived secrets directly in general-purpose environment variables where process environments may be inspected. - Never print gateway tokens to standard output. - Write generated tokens directly into a mode-`600` configuration or secret file. - Provide a separate authenticated administrative command for retrieving or rotating a token. - Configure CI and deployment systems to mask known secret values and restrict log access and retention. - Rotate any credential that has already appeared in shell history or deployment logs. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• System Prompt Leakage: Direct Leakage, Indirect Extraction, Tool-Based Exfiltration
• Rogue Agent: Self-Modification, Session Persistence
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (20)

Direct Prompt Extraction

High

• Category: System Prompt Leakage

Content

### If Interactive TUI Still Appears

Some versions of aleph-client may still show prompts. Use pexpect:

```python
#!/usr/bin/env python3

• Confidence: 85% confidence
• Finding: Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.

Intent-Code Divergence

High

• Confidence: 98% confidence
• Finding: The document explicitly says never to log or echo private keys, but later activates an account by passing the private key inline on the command line via `--private-key $(cat ...)`. Command-line arguments can be exposed through shell history, process listings, audit logs, or orchestration telemetry, making wallet compromise much more likely.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Step 1: Account Setup

### Import or Create a Private Key

```bash
# Import existing private key

• Confidence: 89% confidence
• Finding: The skill instructs importing or creating a long-lived private key for automated instance control and later reuses that credential to enable recursive self-deployment. Persisting such wallet keys on disk across autonomous child instances expands the blast radius of any host compromise and creates durable access to billing and provisioning functions.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

aleph account create --chain BASE --active
```

Keys are stored at `~/.aleph-im/private-keys/`. Always `chmod 600` key files.

### Check Balance

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

aleph account create --chain BASE --active
```

Keys are stored at `~/.aleph-im/private-keys/`. Always `chmod 600` key files.

### Check Balance

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

aleph account create --chain BASE --active
```

Keys are stored at `~/.aleph-im/private-keys/`. Always `chmod 600` key files.

### Check Balance

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

aleph account create --chain BASE --active
```

Keys are stored at `~/.aleph-im/private-keys/`. Always `chmod 600` key files.

### Check Balance

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

aleph account create --chain BASE --active
```

Keys are stored at `~/.aleph-im/private-keys/`. Always `chmod 600` key files.

### Check Balance

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

EOF

# Harden permissions
chmod 700 /root/.openclaw
chmod 600 /root/.openclaw/openclaw.json
```

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

EOF

# Harden permissions
chmod 700 /root/.openclaw
chmod 600 /root/.openclaw/openclaw.json
```

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Skill Enumeration

Medium

• Category: Agent Snooping

Content

echo -n "aleph-client: "; aleph --version
echo -n "Balance: "; aleph account balance 2>&1 | head -3
echo -n "SSH key: "; ls ~/.ssh/aleph_agent.pub 2>/dev/null && echo "OK" || echo "MISSING — generate with: ssh-keygen -t ed25519 -f ~/.ssh/aleph_agent -N ''"
echo -n "This skill: "; ls ~/openclaw/skills/aleph-vm-deployment/SKILL.md 2>/dev/null && echo "OK" || echo "MISSING"
echo -n "OpenClaw: "; openclaw --version
echo "=== Ready to deploy ==="
REMOTE

• Confidence: 80% confidence
• Finding: Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

}
CONF

chmod 700 /root/.openclaw
chmod 600 /root/.openclaw/openclaw.json

echo "=== Starting gateway ==="

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

CONF

chmod 700 /root/.openclaw
chmod 600 /root/.openclaw/openclaw.json

echo "=== Starting gateway ==="
openclaw gateway install --force

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

CONF

chmod 700 /root/.openclaw
chmod 600 /root/.openclaw/openclaw.json

echo "=== Starting gateway ==="
openclaw gateway install --force

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

CONF

chmod 700 /root/.openclaw
chmod 600 /root/.openclaw/openclaw.json

echo "=== Starting gateway ==="
openclaw gateway install --force

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The skill's security guidance says API keys should not be stored in config files, yet the instructions create `auth-profiles.json` containing the Anthropic token. This contradiction encourages persistent plaintext secret storage on disk, increasing the chance of credential theft through file disclosure, backup leakage, or compromise of the spawned VM.

Session Persistence

Medium

• Category: Rogue Agent

Content

sleep 3
openclaw gateway status --token "$GATEWAY_TOKEN"
```
The systemd service file caches the token — `install --force` re-syncs it.

### Interactive TUI Blocks Automation
Use `--crn-hash <HASH>` + `--skip-volume` + `--crn-auto-tac`. If still interactive, use the pexpect script from Step 4.

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

External Script Fetching

Low

• Category: Supply Chain

Content

```bash
# Install Node.js 22
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
DEBIAN_FRONTEND=noninteractive apt-get install -y nodejs git

# Install OpenClaw

• Confidence: 90% confidence
• Finding: Piping a remote script directly into `bash` executes third-party code without verification. If the upstream endpoint, network path, or DNS is compromised, the VM will run attacker-controlled code as root during bootstrap.

Missing User Warnings

Low

• Confidence: 84% confidence
• Finding: The markdown provides a direct `aleph instance delete <INSTANCE_HASH>` command to remove a VM instance, which is a destructive operation that can affect deployed workloads and associated data. Although the document has general security notes elsewhere, this specific deletion step does not include a local warning about irreversibility or verifying the target instance first.

External Script Fetching

Low

• Category: Supply Chain

Content

ANTHROPIC_KEY="${1:-}"

echo "=== Installing Node.js 22 ==="
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
DEBIAN_FRONTEND=noninteractive apt-get install -y nodejs git python3-pip

echo "=== Installing OpenClaw ==="

• Confidence: 90% confidence
• Finding: The setup script repeats the unsafe `curl | bash` pattern in an automation path intended for fresh VMs. Because this runs unattended and typically as root, compromise of the fetched script could fully subvert every deployed child instance.

Static analysis

No suspicious patterns detected.