182 lines
7.0 KiB
Markdown
182 lines
7.0 KiB
Markdown
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.
|