From be1fb2d1027583bb2885f6de2795073c6a1392ce Mon Sep 17 00:00:00 2001 From: Nicholai Date: Tue, 27 Jan 2026 15:38:48 -0700 Subject: [PATCH] docs: initial clawdbot safety report --- README.md | 181 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 181 insertions(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..2270539 --- /dev/null +++ b/README.md @@ -0,0 +1,181 @@ +clawdbot safety report — january 27, 2026 +========================================== + +sources: github issues (#2992-#3002), reddit (r/hackerworkspace, r/MoltbotCommunity), +official security docs (docs.clawd.bot/security), and community discourse. + +note: web search API key is missing so twitter/x couldn't be scraped directly. +findings are based on reddit, github, and official docs which reflect the same +concerns circulating on twitter. + +executive summary +--------- + +the overwhelming majority of "clawdbot got hacked" stories trace back to +**user misconfiguration**, not software vulnerabilities. the most viral +complaints are from marketers who port-forwarded their gateway to the public +internet, got owned, and blamed the software. that said, there ARE real +security issues worth knowing about — mostly around defaults and missing +hardening that new users don't think to configure. + +**verdict:** clawdbot is not inherently insecure. it's a power tool that +requires the user to understand what they're connecting. most incidents are +self-inflicted. + + +critical issues (user-caused) +--------- + +### 1. port forwarding the gateway (the big one) + +**severity: catastrophic (user error)** + +this is what's blowing up twitter. users are port-forwarding port 18789 +to the public internet, effectively giving anyone on earth direct access +to their shell, files, and messaging integrations. clawdbot's gateway is +designed to run on localhost only. exposing it publicly is like giving +strangers your SSH keys. + +**the fix:** never port forward. use messaging integrations (discord, +telegram, signal) as the public-facing layer. gateway should only listen +on 127.0.0.1 (which is actually the default — users are going out of +their way to break this). + +### 2. open DM policy with no allowlist + +**severity: high (user error)** + +some users set dmPolicy to "open" without understanding that this lets +literally anyone trigger their bot. combined with tool access, this means +a random stranger can message your bot and potentially execute commands. + +**the fix:** use dmPolicy: "pairing" or "allowlist". never use "open" +unless you fully understand the implications. + +### 3. sandbox disabled + +**severity: high (user error)** + +users running without sandbox mode, meaning every exec command runs +directly on the host system with full access. one prompt injection away +from `rm -rf /`. + +**the fix:** enable sandbox=all, set docker.network=none for isolation. + +### 4. plaintext credentials + +**severity: medium (user error)** + +oauth.json and other credential files sitting with default permissions. +on multi-user systems, other users can read your tokens. + +**the fix:** chmod 600 on all credential files. use environment variables +for sensitive tokens. run `moltbot security audit --fix` to auto-tighten. + + +real software vulnerabilities (from github) +--------- + +these are actual code-level issues filed on the repo (issues #2992-#3002): + +### critical severity + +- **#2992 — unsafe eval() in browser context:** eval() is used to run + JavaScript in browser automation. if the input is user-influenced, + this is arbitrary code execution. location: pw-tools-core.interactions.ts + +- **#2993 — HTTP without mandatory HTTPS:** the gateway can run plain HTTP, + meaning tokens and credentials transit unencrypted. fine for localhost, + dangerous if exposed to any network. + +### high severity + +- **#2994 — SHA1 still used for hashing:** SHA1 is cryptographically broken. + used in sandbox config hashing. should be SHA-256 minimum. + +- **#2995 — path traversal risk:** not all file operations use the safe + openFileWithinRoot() wrapper. `../` sequences could access files outside + intended directories. + +- **#2996 — JSON.parse without schema validation:** parsing config files + without validation means tampered files could cause unexpected behavior. + +### medium severity + +- **#2997 — hook tokens in query parameters:** deprecated but still supported. + tokens in URLs leak to logs, browser history, referrer headers, and proxies. + +- **#2998 — no explicit CORS policy:** missing Access-Control-Allow-Origin + headers could allow unauthorized cross-origin API requests. + +- **#2999 — environment variable injection:** sanitizeEnv() may not fully + prevent dangerous env vars like LD_PRELOAD or PATH manipulation in + child processes. + +### low severity + +- **#3000 — sensitive data in logs:** logging statements may expose tokens + and API keys. logging.redactSensitive exists but isn't enforced everywhere. + +- **#3001 — inconsistent input validation:** not all HTTP endpoints validate + input consistently. potential for injection or DoS. + +- **#3002 — file permissions not enforced:** sensitive files may be created + without restrictive permissions on multi-user systems. + + +what the community is saying (reddit) +--------- + +**r/hackerworkspace** — post titled "clawdbot is a security nightmare" +links to a youtube video. typical fear-mongering from people who don't +understand the tool. the post itself doesn't detail any novel exploits. + +**r/MoltbotCommunity** — much more constructive post "Secure your Moltbot" +that actually lists practical fixes. this poster gets it — they're +pro-clawdbot but want users to harden their setups. their checklist +largely aligns with the official security docs. + + +what clawdbot already does right +--------- + +- gateway binds to loopback by default (you have to deliberately break this) +- DM policy defaults to "pairing" (strangers can't just message in) +- built-in `moltbot security audit` command that flags common footguns +- `--fix` flag auto-applies safe guardrails +- comprehensive official security docs with threat model documentation +- prompt injection guidance in official docs +- credential storage is documented with clear hardening steps +- model-specific security guidance (recommends opus 4.5 for tool-enabled bots) + + +recommendations +--------- + +1. **run the audit:** `moltbot security audit --deep --fix` regularly +2. **never expose the gateway:** localhost only, always +3. **use allowlists:** for DMs and groups, always use pairing or allowlists +4. **enable sandbox:** sandbox=all with docker.network=none +5. **lock file permissions:** chmod 600 on everything in ~/.clawdbot/ +6. **use strong models:** opus 4.5 for any bot with tool access + (weaker models are more susceptible to prompt injection) +7. **treat all external content as hostile:** web pages, attachments, + pasted content — all potential prompt injection vectors +8. **block dangerous commands:** explicitly block rm -rf, curl pipes, + git push --force unless you need them +9. **enable audit logging:** so if something goes wrong, you know what happened + + +bottom line +--------- + +the twitter meltdown is 90% users who port-forwarded their way into getting +owned, and 10% legitimate (but mostly low-to-medium severity) code issues +that the maintainers are tracking. the software has solid security defaults — +the problem is users actively disabling them without understanding why they +exist. + +anyone blaming clawdbot for getting hacked after port-forwarding their +gateway is like blaming their car manufacturer after leaving the keys in +the ignition with the engine running in a walmart parking lot.