T03 · Remote Payload Retrieval and Execution
- Location
references/gmail-setup.md:77- Finding
Unverified Mutable Remote Executables Are Downloaded and Executed
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a coherent OpenClaw Docker setup guide, but it handles several powerful credentials and downloads in ways that materially increase exposure risk.
Review this skill before installing. Use a pinned OpenClaw image digest, avoid piping unverified latest-release archives into the container, do not print raw secret-bearing config files, replace the fixed Google keyring password with a unique secret, and use dedicated low-privilege bot accounts for Discord, Gmail, and Google Workspace. Rotate any token or app password that has been displayed in terminal output or copied into logs.
references/gmail-setup.md:77Unverified Mutable Remote Executables Are Downloaded and Executed
SKILL.md:161Mutable Container Image Is Trusted with Persistent Data and Service Credentials
references/gmail-setup.md:105Gmail App Password Is Stored, Displayed, and Updated Insecurely
references/google-drive-setup.md:148Google OAuth Token Uses a Predictable Temporary File and Hard-Coded Keyring Password
SKILL.md:278Raw OpenClaw Configuration Is Printed to Bypass Secret Redaction
The guide imports Google OAuth tokens into the container while providing a static keyring password via an environment variable: GOG_KEYRING_PASSWORD=openclaw-isolated. A hardcoded, predictable secret weakens protection of stored credentials because anyone with access to the container config, process environment, logs, or documentation can decrypt or reuse the credential store.
cat /tmp/gog-token-export.json | \
docker exec -i -e GOG_KEYRING_PASSWORD=openclaw-isolated \
openclaw-isolated /home/node/.local/bin/gog auth tokens import /dev/stdin
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).
rm /tmp/gog-token-export.json
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).
rm /tmp/gog-token-export.json
This verification command again exposes reliance on a static environment-variable password for the gog keyring. Although listing auth is legitimate, the dangerous part is normalizing disclosure and reuse of a shared predictable secret that protects OAuth tokens for Google services.
docker exec -e GOG_KEYRING_PASSWORD=openclaw-isolated \
openclaw-isolated /home/node/.local/bin/gog auth list --client isolated
The docker run example permanently sets GOG_KEYRING_PASSWORD=openclaw-isolated in container configuration, making the decryption secret predictable and retrievable through Docker inspection or operational tooling. In the context of a skill that provisions a long-lived bot with Google Drive/Docs/Calendar access, this materially increases the chance of credential compromise.
-v openclaw-isolated-data:/app/data \
-v openclaw-isolated-home:/home/node \
-e NODE_OPTIONS="--max-old-space-size=1024" \
-e GOG_KEYRING_PASSWORD=openclaw-isolated \
-e GOG_CLIENT=isolated \
-e GOG_ACCOUNT=<YOUR_BOT_EMAIL> \
ghcr.io/openclaw/openclaw:latest
This command repeats the same insecure secret-handling pattern during normal operation by passing the predictable keyring password through environment variables at execution time. Repetition increases the likelihood the secret appears in shell history, copied docs, screenshots, automation, and operator habits, making compromise more likely.
# List Drive files from inside container
docker exec -e GOG_KEYRING_PASSWORD=openclaw-isolated \
-e GOG_CLIENT=isolated \
openclaw-isolated /home/node/.local/bin/gog drive ls
The maintenance workflow continues to export tokens and re-import them using the same documented static keyring password. This compounds risk over time because token refreshes are recurring operations, so insecure handling is not one-time but institutionalized in the setup process.
gog auth tokens export <YOUR_BOT_EMAIL> --client isolated --out /tmp/gog-token-export.json --overwrite
cat /tmp/gog-token-export.json |
docker exec -i -e GOG_KEYRING_PASSWORD=openclaw-isolated
openclaw-isolated /home/node/.local/bin/gog auth tokens import /dev/stdin
rm /tmp/gog-token-export.json
The file explicitly describes defeating CLI redaction to reveal an authentication token. That undermines a built-in safety control and can enable unauthorized access to the OpenClaw gateway if the token is exposed, especially given this skill’s focus on deploying a remotely reachable service with browser and Discord integration.
The skill instructs users to pull and run ghcr.io/openclaw/openclaw:latest, which is mutable and can change over time without notice. That creates a supply-chain and reproducibility risk: a later image update could introduce vulnerable or malicious code while the instructions still appear identical.
Although the matched text is docker run -d, the surrounding command launches the same unpinned ghcr.io/openclaw/openclaw:latest image. Running a mutable image tag undermines integrity guarantees and allows silent behavior changes between installs or reinstalls.
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.
> **Pitfall — OOM crash loop:** If the container keeps restarting, check logs:
> `docker logs --tail 20 $INSTANCE`
> If you see `JavaScript heap out of memory`, the container needs `-m 2048m` AND `-e NODE_OPTIONS="--max-old-space-size=1024"`. Recreate with the full command above.
> **Pitfall — port conflict:** If the port is in use, you chose the wrong `HOST_PORT` in Step 0. Re-run the conflict check: `lsof -i :$HOST_PORT`. Pick a free port and relaunch.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
Wait 10 seconds, then verify:
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:$HOST_PORT/
Success: Returns 200.
The update workflow again pulls ghcr.io/openclaw/openclaw:latest, repeating the mutable-tag supply-chain risk. A user following the maintenance section could unknowingly upgrade to an unreviewed image with new vulnerabilities or hostile modifications.
The maintenance docker run example recreates the container from the same mutable image reference, so the deployment is not reproducible or auditable. This is especially relevant because the skill stores persistent auth and workspace data in volumes, increasing the value of a compromised image.
This document materially expands the skill from Docker/OpenClaw installation into enabling persistent Gmail access, email sending, and attachment retrieval. That gives the container a new external communications and data-ingestion capability that is not necessary for basic Docker setup, increasing the attack surface and enabling sensitive data access if the agent or container is compromised.
These steps configure a general-purpose mail client inside the container with credentials that permit reading emails, sending mail, and downloading attachments. In context, this is more dangerous because the skill is supposed to set up an isolated OpenClaw instance, yet it equips that instance with broad exfiltration and inbound file-handling capabilities that can be abused for phishing, data theft, or malicious document retrieval.
The verification step instructs the user to print the entire Himalaya configuration file, which contains the Gmail app password in cleartext. This can leak credentials to terminal scrollback, shell logging, screen recording, or support transcripts, making unauthorized mailbox access possible.
Code scans file system directories looking for sensitive files. This could be reconnaissance for credential theft.
Verify ownership (must show node node):
docker exec openclaw-isolated ls -la /home/node/.config/gogcli/credentials-isolated.json
The guide exports OAuth tokens into /tmp/gog-token-export.json in plaintext and does not clearly warn that this file contains bearer-token material equivalent to account access. On multi-user systems, in backups, shell history, crash artifacts, or weak /tmp handling, this can expose Google Drive/Docs/Calendar access for the bot account.
Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.
The container is launched with ghcr.io/openclaw/openclaw:latest, which uses a mutable tag rather than an immutable digest or pinned version. This can cause supply-chain risk because future pulls may run different code than was reviewed, including a compromised or malicious image.
Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.
The documentation tells the operator to bypass secret redaction by reading the raw config file to recover gateway.auth.token. That directly exposes a live authentication secret and normalizes handling sensitive credentials in cleartext, increasing the chance of accidental disclosure through terminal history, screenshots, logs, or copied output.
The instructions expose /home/node/.openclaw/openclaw.json, which likely contains authentication tokens and other sensitive configuration, without any warning about sensitive data handling. In a setup skill, users are especially likely to copy terminal output into support channels, making disclosure more likely.
The documentation table states CPU limit | 1 core at L513, but the actual docker run commands use --cpus=2 at L166 and again at L446. This is an active contradiction between the file's reference documentation and the commands users are instructed to run.
No suspicious patterns detected.