T03 · Remote Payload Retrieval and Execution
- Location
scripts/setup-optional.sh:5- Finding
Unverified Remote Installer Piped Directly into Bash
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill mostly matches browser setup, but it weakens browser/network safeguards and installs mutable third-party tooling, so it should be reviewed before use.
Install only in an isolated test container or after reviewing and pinning the third-party installs. Avoid running the optional browser-use installer as written, do not reuse personal Chrome profiles or real credentials, and do not use direct CDP to bypass network policy without explicit authorization.
scripts/setup-optional.sh:5Unverified Remote Installer Piped Directly into Bash
scripts/setup.sh:30Unpinned Packages and Repository Content Execute During Setup and Future Tool Launches
scripts/setup.sh:43Direct CDP Launcher Bypasses SSRF Controls and Weakens Browser Isolation
The declared description says this skill initializes a fresh openclaw environment with Chromium, system dependencies, Chinese fonts, and a CDP launcher script. The provided code instead performs an optional two-step network installation: piping a remote install script from browser-use.com into bash, and installing a browser-use skill from GitHub using npx. Its printed messages and final instruction to register an API key indicate a different primary purpose: setting up browser-use tooling, not provisioning the described browser environment. This is a material description-behavior mismatch.
A setup-only skill should not normalize weakening browser sandbox or network restrictions beyond what is strictly required. Telling operators to work around policy failures rather than respect them expands the skill from initialization into security-control circumvention.
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
sleep 2
curl -s http://localhost:9223/json | python3 -m json.tool | head -20
The guide explicitly instructs users to switch to direct CDP when the built-in browser reports 'blocked by policy,' which is effectively guidance for bypassing a security control. Even if intended for reliability, documenting a fallback around SSRF protections enables access patterns the platform deliberately tried to prevent.
curl ... | bash is a direct remote-code-execution pattern: any content returned by the remote server is executed immediately. Because this skill is meant for one-time machine setup, successful exploitation could install persistent malware, alter test tooling, steal secrets, or compromise subsequent browser-based automation.
# Failures here are non-fatal — main testing flow works without browser-use.
echo "=== [opt 1/2] Installing browser-use CLI ==="
curl -fsSL --retry 3 https://browser-use.com/cli/install.sh | bash || {
echo " ⚠ browser-use CLI install failed. Retry manually:"
echo " curl -fsSL https://browser-use.com/cli/install.sh | bash"
}
The script downloads shell code from browser-use.com and pipes it directly into bash, granting immediate code execution from a remote server at install time. In the context of a setup skill for fresh environments, this is especially dangerous because users may run it with high trust and little review, making compromise of the remote endpoint or network path highly impactful.
Even though this occurrence is in an error message, it instructs users to manually execute the same unsafe remote-script-to-shell command. Troubleshooting guidance that promotes insecure execution patterns can propagate the vulnerability beyond the automated path and normalize dangerous operator behavior.
echo "=== [opt 1/2] Installing browser-use CLI ==="
curl -fsSL --retry 3 https://browser-use.com/cli/install.sh | bash || {
echo " ⚠ browser-use CLI install failed. Retry manually:"
echo " curl -fsSL https://browser-use.com/cli/install.sh | bash"
}
echo "=== [opt 2/2] Installing browser-use skill ==="
The skill invokes shell commands (bash, cp, curl) but does not declare any tool scope or permission boundaries. That omission weakens governance and makes it harder for a calling system or reviewer to understand that the skill can execute code and modify the local environment.
The trigger phrase setup browser is broad enough to match common user requests, increasing the chance this skill runs in contexts where one-time environment initialization was not intended. Because the skill executes shell commands and changes local configuration, accidental invocation can have real side effects.
The documentation instructs users to modify an SSRF allowlist and, if policy enforcement still blocks navigation, to abandon the built-in browser and switch to direct CDP. That is effectively guidance for bypassing browser/network access controls, which can expose internal services or otherwise defeat intended security boundaries.
Reusing the user's local Chrome profile can expose cookies, active sessions, saved credentials, and other sensitive browsing artifacts to automation. Without an explicit warning, consent boundary, and data-handling restrictions, this creates avoidable privacy and account-takeover risk.
Recommending internal network tunneling without clear guardrails can expose private services or enable access to internal-only resources from automation tooling. In this context, the skill already discusses policy-block bypasses, which makes tunnel guidance more dangerous because it expands reachable attack surface.
The file is scoped as a one-time browser setup skill, but it includes extensive operational guidance for browser automation, login flows, credential entry, policy-block handling, and runtime workarounds. That mismatch materially increases risk because operators may use the skill to access authenticated services or bypass platform safeguards under the guise of setup.
Code issues a request to a loopback, link-local, or private-range host. This can reach internal services not meant to be exposed and is a common SSRF pivot.
}
(async () => {
const targets = await (await fetch('http://localhost:9223/json')).json();
const ws = new WebSocket(targets[0].webSocketDebuggerUrl);
await new Promise(r => ws.on('open', r));
The CDP login example automates entry of email and password values directly into a script without any warning about secrets handling, storage, or logging. This normalizes embedding credentials in code and can lead to accidental disclosure through shell history, files, logs, or workspace artifacts.
This optional setup installs an additional third-party CLI and skill that are not necessary for the stated purpose of local Chromium/CDP environment initialization. Expanding the trust boundary in a bootstrap script increases attack surface and may cause users to execute extra code they would not reasonably expect from the skill description.
The script invokes npx skills add without pinning the package version or otherwise constraining what code is executed. That means future upstream changes or a compromised dependency path could alter installation behavior unexpectedly, which is risky in a setup script that users are expected to run on fresh machines.
The fallback instruction repeats an unpinned npx skills add command, encouraging users to manually run an unconstrained package resolver. This extends supply-chain risk from the script itself to operator copy-paste behavior during troubleshooting.
The script downloads and executes @playwright/mcp via npx without pinning a specific version. That makes the setup non-reproducible and exposes the environment to supply-chain risk if the package publishes a malicious update or if dependency resolution is compromised.
The generated launcher starts Chromium with --remote-debugging-port, --remote-allow-origins='*', --no-sandbox, and a fixed --user-data-dir=/tmp/chrome-cdp-profile. This creates a persistent debuggable browser profile with weakened isolation; if another local process or exposed network path can reach the CDP port, an attacker may fully control the browser session, inspect data, and execute actions in that context.
# ── [2/3] Chrome CDP launcher script ──────────────────────
echo "=== [2/3] Creating chrome-cdp launcher ==="
mkdir -p "$HOME/.local/bin"
cat > "$HOME/.local/bin/chrome-cdp" << WRAPPER
#!/bin/bash
exec "$CHROME_BIN" \\
Beyond installing Chromium and fonts, the script globally installs the ws Node package and registers a Playwright MCP server. These actions expand the agent's execution surface and persistence beyond simple browser setup, which is risky because they introduce additional remotely updateable code and alter future agent behavior.
The script changes the agent/browser runtime by registering Playwright MCP and then instructs the operator to edit openclaw configuration, including browser sandbox and SSRF policy settings. In context, that is more dangerous than ordinary setup because it can weaken runtime isolation and network protections for subsequent browser sessions.
No suspicious patterns detected.