T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:268- Finding
Unpinned Remote Installation Script Is Executed Directly by a Shell
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a disclosed setup guide, but it asks users to create persistent host network bridges and broad agent permissions that weaken the sandbox boundary it claims to provide.
Review this carefully before installing. It is not clearly malicious, but it makes host-level and persistent networking changes, grants broad agent/session capabilities, uses a remote installer script, enables broad Discord intents, and documents root SSH with host-key checking disabled. Use a dedicated host or test environment, restrict Docker networking to the intended container, avoid bridging the gateway unless strictly required, use a non-root VPS account, pin and verify installers, keep SSH host-key verification enabled, and document how to disable and remove the services.
SKILL.md:268Unpinned Remote Installation Script Is Executed Directly by a Shell
SKILL.md:157Persistent Network Bridges Expose Host and VPS Services to Docker Workloads
SKILL.md:293SSH Server Identity Verification Is Disabled for a Root Connection
SKILL.md:52Sandbox Agent Is Granted Excessive Session and Agent-Orchestration Capabilities
SKILL.md:209Discord Bot Is Instructed to Enable Unnecessary Privileged Gateway Intents
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).
bash ca-certificates curl git jq
openssh-client
python3 ripgrep
&& rm -rf /var/lib/apt/lists/*
Rebuild and force-recreate containers:
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).
bash ca-certificates curl git jq
openssh-client
python3 ripgrep
&& rm -rf /var/lib/apt/lists/*
Rebuild and force-recreate containers:
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
bash ca-certificates curl git jq
openssh-client
python3 ripgrep
&& rm -rf /var/lib/apt/lists/*
Rebuild and force-recreate containers:
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
docker build -f Dockerfile.sandbox -t openclaw-sandbox:bookworm-slim .
docker ps --format "{{.ID}} {{.Image}}" | grep sandbox | awk '{print $1}' | xargs -r docker rm -f
Piping a remote script directly into sh executes unreviewed network content with full installer privileges, creating a strong supply-chain and content-injection risk. If the remote endpoint, transport, or DNS is compromised, the operator may run attacker-controlled code on every machine involved in the multi-agent infrastructure.
Install on all machines:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh
The | sh chain is dangerous because it turns a remote fetch directly into code execution without review or integrity verification. This is especially sensitive here because the commands are run on infrastructure hosts that provide cross-agent connectivity and persistence.
Install on all machines:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh
The skill claims the sandbox isolates private data, but it explicitly grants the sandbox broad messaging and session tools such as sessions_send, sessions_history, sessions_list, and message. Those capabilities create a practical exfiltration path from the sandbox workspace to other agents or external channels, so the isolation claim is overstated unless strict data-flow controls are added.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Enable, start, and open firewall:
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Enable, start, and open firewall:
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Enable, start, and open firewall:
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Enable, start, and open firewall:
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Enable, start, and open firewall:
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Enable, start, and open firewall:
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"
The skill instructs operators to enable persistent host services that automatically recreate network bridges across reboots. Persistence is intentional here, but it still increases attack surface because a misconfigured or later-compromised bridge remains available continuously and survives restarts.
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"
The documented SSH command uses StrictHostKeyChecking=no, which disables host identity verification and makes man-in-the-middle interception much easier. In this design, the SSH path bridges containers to a shared VPS, so trust on first use or disabled verification materially weakens the boundary protecting shared workspace access.
The key-constraints section states "all exec runs through Docker, never on host," which reads as a broad safety/property claim. However, the skill's actual procedure depends on host modifications including systemd service creation, UFW changes, Tailscale installation, and Docker image rebuilds, so the statement overstates the effective boundary described by the overall instructions.
No suspicious patterns detected.