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

run the audit: moltbot security audit --deep --fix regularly
never expose the gateway: localhost only, always
use allowlists: for DMs and groups, always use pairing or allowlists
enable sandbox: sandbox=all with docker.network=none
lock file permissions: chmod 600 on everything in ~/.clawdbot/
use strong models: opus 4.5 for any bot with tool access (weaker models are more susceptible to prompt injection)
treat all external content as hostile: web pages, attachments, pasted content — all potential prompt injection vectors
block dangerous commands: explicitly block rm -rf, curl pipes, git push --force unless you need them
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.