T03 · Remote Payload Retrieval and Execution
- Location
references/install.md:42- Finding
Unverified Remote Installer Scripts Are Executed Directly
- Content
View full analysis
Vulnerability Details
File Location:
references/install.md:42-54and additional installation documents listed below
Vulnerability Type: Remote payload retrieval followed by immediate shell execution
Risk Level: CriticalEvidence
The primary installation guide recommends executing mutable remote responses directly:
sh curl -fsSL https://openclaw.ai/install.sh | bashThe Windows equivalent has the same trust-boundary issue:
powershell iwr -useb https://openclaw.ai/install.ps1 | iexThe guide also supplies an unattended variant:
sh curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboardOther confirmed examples include:
sh curl -fsSL https://raw.githubusercontent.com/openclaw/openclaw-ansible/main/install.sh | bash RUN curl -fsSL https://bun.sh/install | bash curl -fsSL https://get.docker.com | sh /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh))"The Homebrew example appears at
references/help/faq.md:1136; its actual documented command has a single closing parenthesis:sh /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"The same pattern was confirmed at:
references/install.md:42,47,54references/start/getting-started.md:41,46references/help/faq.md:666,701,841,846,877,896,902,908,950,1136,1831references/install/ansible.md:42references/install/docker.md:290references/install/exe-dev.md:83references/install/hetzner.md:116references/install/installer.md:38,43,48,53,58,105,110,115,120,144,149,154,159,188,227,233,238,255references/install/macos-vm.md:95references/install/updating.md:37,47references/reference/RELEASING.md:70
Technical Analysis
These commands combine retrieval and execution into one operation. The downloaded content is not pinned to an immutable version and is not authenticated through a published checksum or digital signat ...[truncated 2728 chars]
- Remediation
View remediation
Remediation Suggestions
-
Replace every pipe-to-shell and
Invoke-Expressionexample with a staged installation process:- Download the installer to a local file.
- Retrieve its checksum or signature through a separately authenticated release channel.
- Verify the artifact before execution.
- Allow the user to inspect it.
- Execute it only after explicit confirmation.
-
Pin installer artifacts to immutable release versions. For GitHub-hosted material, use a reviewed commit hash or signed release asset rather than
main,HEAD, orlatest. -
Publish SHA-256 or stronger checksums and sign releases using a documented mechanism such as Sigstore, minisign, or GPG. Pin the expected signing identity or public key in the documentation.
-
Prefer package-manager installation where package integrity and provenance controls are available. Document exact package names and versions to reduce dependency-confusion and unexpected-update risks.
-
Avoid running installation steps as root unless a specific operation requires it. Separate unprivileged download and validation from narrowly scoped privileged installation actions.
-
For automation and CI, use version-pinned artifacts stored in an approved internal mirror or artifact registry rather than downloading and executing mutable scripts during every run.
-
Add an explicit warning that HTTPS alone does not verify script provenance and that users should not execute an installer when checksum or signature verification fails.
A safer pattern is:
sh curl --fail --location --proto '=https' --tlsv1.2 \ --output openclaw-install.sh \ 'https://example.invalid/releases/openclaw-VERSION/install.sh' printf '%s %s\n' 'PUBLISHED_SHA256' 'openclaw-install.sh' | sha256sum --check - less openclaw-install.sh bash openclaw-install.shThe real documentation should substitute a versioned first-party release URL and an independently published, verified checksum or signature.
-