T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:71- Finding
Remote Tailscale Installer Is Executed Without Integrity Verification
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a legitimate failover setup guide, but it needs Review because it installs a persistent root-level monitor and uses unverified remote installer commands.
Review before installing on a real server. Prefer verified package repositories or pinned checksums instead of curl-pipe installers, run the monitor under a dedicated least-privilege account with systemd hardening, avoid broad sudo access, use authenticated health checks, and treat optional secret rsync as sensitive production credential handling.
SKILL.md:71Remote Tailscale Installer Is Executed Without Integrity Verification
SKILL.md:79Remote NVM Installer Is Executed Without Cryptographic Verification
SKILL.md:142Boot-Persistent Health Monitor Runs With Unrestricted Root Privileges
SKILL.md:79Unpinned Node.js and Global OpenClaw Installation Expose the Deployment to Supply-Chain Changes
scripts/health-monitor.sh:24Failover State Is Controlled by an Unauthenticated Plaintext HTTP Health Check
The guide instructs users to fetch and execute a remote installer script directly from the network using a shell pipe. If the source, transport, DNS, or upstream account is compromised, arbitrary code runs immediately on the standby host, likely with elevated privileges during setup.
curl -fsSL https://tailscale.com/install.sh | sh tailscale up --hostname=your-failover-name
Piping curl output directly into sh removes opportunities for inspection and compounds the supply-chain risk by turning a network response into immediate code execution. In a deployment guide for infrastructure nodes, this is especially dangerous because compromise of the failover host can undermine resilience and expose secrets or tokens.
curl -fsSL https://tailscale.com/install.sh | sh tailscale up --hostname=your-failover-name
Using curl piped to bash for the nvm install similarly enables instant execution of unverified remote content. The risk is somewhat lower than a root-level installer if run as an unprivileged user, but it can still compromise the openclaw account, workspace, tokens, and subsequent operational workflows.
# As openclaw user
curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.bashrc
nvm install --lts
npm install -g openclaw
The skill contains multiple shell commands, privileged operations, and service-management steps but does not declare any tool scope or permissions boundary. In an agent ecosystem, this increases the chance that automation executes impactful system changes without explicit user awareness or policy enforcement.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Copy the included scripts/health-monitor.sh to the standby:
sudo cp health-monitor.sh /usr/local/bin/openclaw-health-monitor.sh
sudo chmod +x /usr/local/bin/openclaw-health-monitor.sh
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Copy the included scripts/health-monitor.sh to the standby:
sudo cp health-monitor.sh /usr/local/bin/openclaw-health-monitor.sh
sudo chmod +x /usr/local/bin/openclaw-health-monitor.sh
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Copy the included scripts/health-monitor.sh to the standby:
sudo cp health-monitor.sh /usr/local/bin/openclaw-health-monitor.sh
sudo chmod +x /usr/local/bin/openclaw-health-monitor.sh
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Copy the included scripts/health-monitor.sh to the standby:
sudo cp health-monitor.sh /usr/local/bin/openclaw-health-monitor.sh
sudo chmod +x /usr/local/bin/openclaw-health-monitor.sh
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Copy the included scripts/health-monitor.sh to the standby:
sudo cp health-monitor.sh /usr/local/bin/openclaw-health-monitor.sh
sudo chmod +x /usr/local/bin/openclaw-health-monitor.sh
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Copy the included scripts/health-monitor.sh to the standby:
sudo cp health-monitor.sh /usr/local/bin/openclaw-health-monitor.sh
sudo chmod +x /usr/local/bin/openclaw-health-monitor.sh
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Copy the included scripts/health-monitor.sh to the standby:
sudo cp health-monitor.sh /usr/local/bin/openclaw-health-monitor.sh
sudo chmod +x /usr/local/bin/openclaw-health-monitor.sh
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.
sudo systemctl daemon-reload
sudo systemctl enable openclaw-health-monitor
sudo systemctl start openclaw-health-monitor
# Do NOT enable openclaw.service — the monitor controls it
The test procedure tells the operator to stop the primary gateway to simulate failure but does not clearly warn that this intentionally disrupts production service and may trigger user-visible downtime or message loss. In a high-availability guide, destructive validation is legitimate, but omitting an explicit disruption warning makes accidental unsafe execution more likely.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
log() { logger -t "$LOG_TAG" "$1"; echo "$(date -Is) $1"; }
check_primary() {
curl -sf -o /dev/null --connect-timeout 5 \
"http://${PRIMARY_IP}:${PRIMARY_PORT}/health" 2>/dev/null
}
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# Pull latest workspace from git (best effort)
if [ -d "$WORKSPACE/.git" ]; then
cd "$WORKSPACE"
sudo -u "$OPENCLAW_USER" git pull --ff-only 2>&1 | logger -t "$LOG_TAG" \
|| log "WARNING: git pull failed, using last sync"
fi
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# Pull latest workspace from git (best effort)
if [ -d "$WORKSPACE/.git" ]; then
cd "$WORKSPACE"
sudo -u "$OPENCLAW_USER" git pull --ff-only 2>&1 | logger -t "$LOG_TAG" \
|| log "WARNING: git pull failed, using last sync"
fi
The script automatically rsyncs secrets from a remote host during promotion without any visible integrity verification, host key pinning, or restriction on what is synchronized. In a failover context this is more dangerous because compromise, misconfiguration, or spoofing of SECRETS_HOST could poison the standby with attacker-controlled credentials or overwrite local secret material right before service startup.
# Sync secrets from remote host (optional, best effort)
if [ -n "$SECRETS_HOST" ]; then
sudo -u "$OPENCLAW_USER" rsync -a "${SECRETS_HOST}:~/.secrets/" \
"/home/${OPENCLAW_USER}/.secrets/" 2>&1 | logger -t "$LOG_TAG" \
|| log "WARNING: secrets sync failed, using cached"
fi
The skill also fetches and executes the nvm installer directly from a remote URL. Although common in practice, it still creates a supply-chain execution path where a compromised upstream or network path can run arbitrary code on the target machine.
# As openclaw user
curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.bashrc
nvm install --lts
npm install -g openclaw
No suspicious patterns detected.