T03 · Remote Payload Retrieval and Execution
- Location
README.md:26- Finding
Execution of an Unverified and Mutable Remote Installer
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill openly aims to be an autonomous developer, but it asks for unverified remote code execution, broad account credentials, plaintext secret storage, and persistent background operation that require careful review before use.
Review this carefully before installing. Do not run the curl-to-bash installer unless you have independently verified and pinned the engine source. Use disposable or least-privilege accounts, avoid delete_repo and broad classic GitHub tokens, do not provide a Google account password, and assume the system may keep running and acting until you stop the service and revoke stored tokens.
README.md:26Execution of an Unverified and Mutable Remote Installer
prompts/setup.md:470Cross-Session Persistence and Indefinite Autonomous Execution
prompts/setup.md:94Plaintext Credential Storage and Unsafe Shell Sourcing
prompts/setup.md:177Excessive GitHub Token Scopes Combined with Broad Autonomous Tool Access
prompts/setup.md:61Skill Instructions Override Normal Confirmation and Session-Control Boundaries
The use of '| bash' is a classic dangerous chaining pattern because it turns a network fetch directly into code execution with no validation, inspection, or opportunity to detect tampering. In this context, where the installed engine is intended to autonomously perform development, publishing, and account-related actions, exploitation could quickly extend from local code execution to credential access, repository abuse, and unauthorized publishing.
export FORGE_GITHUB_USER=your-username
curl -fsSL https://raw.githubusercontent.com/$FORGE_GITHUB_USER/forge/main/install.sh | bash
Then install this skill and say forge start.
The prompt explicitly states the agent will run autonomously through Telegram and OpenClaw and load further instructions automatically after setup. This establishes an ongoing autonomous control plane rather than a bounded one-time configuration workflow, increasing the risk of unchecked actions, credential misuse, and persistent unauthorized behavior.
The skill instructs the user to run a remote install script fetched over the network and piped directly to bash. This is dangerous because it executes unreviewed remote code immediately, enabling arbitrary code execution if the source is compromised, replaced, or maliciously modified.
Piping curl output directly into bash creates a classic chaining-abuse pattern that removes the opportunity for inspection between download and execution. If the remote source or network path is compromised, the user immediately executes attacker-controlled shell commands.
Run this in your terminal:
curl -fsSL https://raw.githubusercontent.com/[USERNAME]/forge/main/install.sh | bash
Reply "done" when complete.
The setup collects API keys, tokens, passwords, and identifiers and stores them in plaintext without a clear user-facing warning about the associated security and privacy risks. Plaintext secret storage materially increases the chance of local compromise, accidental disclosure, backup leakage, or later exfiltration by other processes.
The instructions direct the agent to collect and persist user secrets and identifiers in a local env file during setup. Centralizing high-value credentials in a plaintext file creates a single point of compromise that can expose multiple external accounts and services simultaneously.
Creating and relying on ~/.forge/.env as the repository for collected credentials establishes a local secret store accessible to any later process with file access. In this skill, that file becomes a central aggregation point for multiple high-value secrets, increasing compromise impact significantly.
"evolution_generation": 0 } EOF [ -f ~/.forge/.env ] || touch ~/.forge/.env
Send:
This setup flow directs the agent to create and operate third-party accounts, automate browser signups, and generate API tokens across multiple services. That exceeds a normal setup assistant role and grants broad identity- and account-level control that could be abused for impersonation, unauthorized account operations, or persistence across external platforms.
Appending the Gemini API key directly into ~/.forge/.env stores a high-value credential in plaintext for later reuse. Any local compromise, shell history mistake, backup exposure, or unintended file read could leak the key and enable unauthorized API usage or billing abuse.
On valid:
echo 'GEMINI_API_KEY="[KEY]"' >> ~/.forge/.env
Send: "Gemini key verified."
The Google account creation path solicits and stores generated passwords while also asking the user for phone verification data. This concentrates sensitive authentication material and personally identifiable information in the agent workflow, making compromise materially more harmful.
Storing a generated Google password in ~/.forge/.env is especially dangerous because it preserves a reusable primary account credential, not just an API token. Compromise of this file could allow direct account takeover and access to linked Google services.
Navigate accounts.google.com via CDP. Automate signup. Store generated password:
echo 'GOOGLE_PASSWORD="[pw]"' >> ~/.forge/.env
On phone verification: Send: "Google needs to verify a phone number.
The setup requests a GitHub classic token with broad scopes including delete_repo, which permits destructive actions far beyond basic integration needs. Without a prominent warning and clear justification, this exposes the user's repositories, workflows, and organizational data to severe account impact if the token is misused or leaked.
Writing the GitHub token to ~/.forge/.env persists a credential that may allow repository access, workflow control, and potentially destructive operations depending on scopes. In this prompt, the requested scopes are broad, making storage compromise especially severe.
Store:
echo 'GITHUB_TOKEN="[TOKEN]"' >> ~/.forge/.env
echo 'GITHUB_USERNAME="'$USERNAME'"' >> ~/.forge/.env
Send: "GitHub connected as [username]."
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Store:
echo 'GITHUB_TOKEN="[TOKEN]"' >> ~/.forge/.env
echo 'GITHUB_USERNAME="'$USERNAME'"' >> ~/.forge/.env
Send: "GitHub connected as [username]."
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Store:
echo 'GITHUB_TOKEN="[TOKEN]"' >> ~/.forge/.env
echo 'GITHUB_USERNAME="'$USERNAME'"' >> ~/.forge/.env
Send: "GitHub connected as [username]."
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Store:
echo 'GITHUB_TOKEN="[TOKEN]"' >> ~/.forge/.env
echo 'GITHUB_USERNAME="'$USERNAME'"' >> ~/.forge/.env
Send: "GitHub connected as [username]."
Persisting the ClawHub token in ~/.forge/.env creates the same plaintext secret-storage issue seen with other service credentials. If exposed, an attacker could authenticate to the associated external platform and act as the user or agent.
Store:
echo 'CLAWHUB_TOKEN="[TOKEN]"' >> ~/.forge/.env
echo 'CLAWHUB_USERNAME="'$USERNAME'"' >> ~/.forge/.env
Send: "ClawHub connected as [username]."
The Telegram setup obtains and stores a bot token and chat ID via conversation, then persists them locally. Bot tokens provide full control of the bot and can be abused for message sending, command control, and impersonation if disclosed or mishandled.
Writing the Telegram bot token into ~/.forge/.env persists a powerful credential that controls the bot's behavior and messaging. Disclosure could let an attacker impersonate the bot, send messages, change settings, or abuse it as a command channel.
Store:
echo 'TELEGRAM_TOKEN="[TOKEN]"' >> ~/.forge/.env
echo 'TELEGRAM_CHAT_ID="[ID]"' >> ~/.forge/.env
Adding API keys into an agent-managed keyring still involves collecting and retaining high-value secrets within the tool's control plane. Without clear storage protections and retention constraints, this creates another persistent credential repository susceptible to misuse or compromise.
python3 ~/.forge/engine/scripts/validate_key.py gemini [KEY]
On valid, add to keyring:
python3 ~/.forge/engine/keyring/keyring.py add gemini [KEY] "gemini-2"
The repeated solicitation of additional API keys encourages accumulation of multiple live credentials, increasing total blast radius if the agent or host is compromised. More keys also enable longer autonomous operation, which heightens risk in this skill's already broad operational context.
On valid, add to keyring:
```bash
python3 ~/.forge/engine/keyring/keyring.py add gemini [KEY] "gemini-2"
Send: "Added. Paste another, or reply done." Repeat until user replies "done".
This duplicate match still reflects the same underlying issue: persistent shell-profile sourcing of a secret-bearing env file. Such persistence increases unintended credential propagation and long-term exposure beyond the setup process.
Shell profile:
grep -q "forge" ~/.bashrc || \
echo '[ -f ~/.forge/.env ] && source ~/.forge/.env' >> ~/.bashrc
[ -f ~/.zshrc ] && grep -q "forge" ~/.zshrc || \
echo '[ -f ~/.forge/.env ] && source ~/.forge/.env' >> ~/.zshrc 2>/dev/null || true
This duplicate match still reflects the same underlying issue: persistent shell-profile sourcing of a secret-bearing env file. Such persistence increases unintended credential propagation and long-term exposure beyond the setup process.
Shell profile:
grep -q "forge" ~/.bashrc || \
echo '[ -f ~/.forge/.env ] && source ~/.forge/.env' >> ~/.bashrc
[ -f ~/.zshrc ] && grep -q "forge" ~/.zshrc || \
echo '[ -f ~/.forge/.env ] && source ~/.forge/.env' >> ~/.zshrc 2>/dev/null || true
Persistently adding a command to source ~/.forge/.env from shell startup files matches a persistence mechanism because it ensures FORGE-controlled environment variables load in future sessions. In this context, the behavior is especially dangerous because the sourced file contains accumulated credentials, making them persistently available and easier to abuse.
rname": "[username]", "opencode_verified": true, "opencode_default_model": "gemini-2.0-flash", "browser_binary": "$(cat ~/.forge/engine/.browser_binary)", "workspace": "$HOME/.forge/workspace", "gateway": "[both|telegram]", "evolution_generation": 0, "mutation_strategy": "fork_test_promote", "parallel_forks_max": 3 } EOF
Shell profile:
```bash
grep -q "forge" ~/.bashrc || \
echo '[ -f ~/.forge/.env ] && source ~/.forge/.env' >> ~/.bashrc
[ -f ~/.zshrc ] && grep -q "forge" ~/.zshrc || \
echo '[ -f ~/.forge/.env ] && source ~/.forge/.env' >> ~/.zshrc 2>/dev/null || true
Update state.json: setup_complete: true, wizard_step: "complete", phase: "research".
Start the engine:
systemctl --user start forge 2>/dev/null || \
bash ~/.forge/engine/scripts/start_runner.sh
Send this final message:
⚒ FORGE is ignited.
Identity Name [name] GitHub github.com/[github_username] ClawHub clawhub.dev/[clawhub_username]
Stack
This duplicate finding captures the same insecure shell-profile persistence on the zsh path. The dangerous aspect is the default, repeated loading of a plaintext secret file into user sessions.
grep -q "forge" ~/.bashrc ||
echo '[ -f ~/.forge/.env ] && source ~/.forge/.env' >> ~/.bashrc
[ -f ~/.zshrc ] && grep -q "forge" ~/.zshrc ||
echo '[ -f ~/.forge/.env ] && source ~/.forge/.env' >> ~/.zshrc 2>/dev/null || true
Update state.json: setup_complete: true, wizard_step: "complete", phase: "research".
No suspicious patterns detected.