Clawdbot Security Risks and VPS Deployment Best Practices
Security vulnerability analysis of Clawdbot's unauthenticated gateway port exposing API keys and browser access, with Cloudflare Tunnel mitigation recommendations.
Clawdbot Security Alert: Unauthenticated Port Exposure and How to Fix It with Cloudflare Tunnel
Category: DevOps | Published: March 4, 2026
Security researcher and developer @op7418 recently flagged a serious vulnerability in Clawdbot deployments that every AI automation engineer should know about before spinning up a VPS instance. The short version: Clawdbot's gateway port is wide open, and your API keys may already be exposed.
Let's break down exactly what's happening, why it matters, and how to close the gap with a zero-cost mitigation using Cloudflare Tunnel.
The Problem: Port 18789 Has No Authentication Whatsoever
Clawdbot ships with a built-in gateway that listens on port 18789. Under the hood, this gateway acts as a local proxy layer coordinating browser automation tasks and routing API calls. That sounds reasonable for a local setup — but the moment you move Clawdbot to a VPS and that port becomes publicly reachable, you have a significant problem.
What is actually exposed on port 18789?
- Your raw API keys stored and passed through the gateway
- Direct browser session access — any connected browser instances Clawdbot is controlling
- Full read/write control over automation workflows running inside the process
The gateway implements zero authentication. No token, no basic auth, no IP allowlist out of the box. Anyone who can reach your server's IP on that port gets the same level of access as you do.
This is not a theoretical edge case. Any internet-facing VPS with default firewall settings — or worse, no firewall at all — is actively exploitable right now. A simple port scan followed by a direct HTTP request is all it takes.
# What an attacker sees when they hit an unprotected Clawdbot instance
curl http://<your-vps-ip>:18789/api/keys
# Response: your API credentials, in plaintext
The underlying issue is an architectural assumption that Clawdbot was designed for localhost use only. The moment you expose that surface area to the public internet without a protective layer in front of it, the design breaks completely.
Why This Is Worse Than a Typical Exposed Port
Most developers understand the general risk of exposed ports. But Clawdbot's exposure is particularly damaging for a few specific reasons worth calling out.
1. API Key Exfiltration Is Immediate and Silent
If someone pulls your API keys through the gateway, you won't know. There are no built-in audit logs, no rate limiting, no anomaly detection. The attacker has a clean window to harvest credentials and use them on third-party services — potentially running up costs or accessing sensitive downstream systems — before you notice anything unusual.
2. Browser Control Is a Full Attack Surface
Clawdbot's browser automation capability is the whole point of the tool. But remotely controllable browser sessions mean an attacker can:
- Navigate authenticated sessions you have open
- Exfiltrate cookies and session tokens
- Perform actions on your behalf inside logged-in applications
- Use the browser as a pivot point into internal network resources if your VPS is on a private network
This goes well beyond a simple data leak. It's remote code execution in functional terms.
3. The Default Configuration Encourages Risk
Clawdbot's documentation and setup flow does not prominently warn users that VPS deployment changes the security model. Developers who follow the standard install guide and then run it on a remote server are unknowingly vulnerable. The tool's rough edges here aren't just cosmetic — they have real operational impact.
The Fix: Cloudflare Tunnel as a Zero-Cost Authentication Layer
The recommended mitigation is straightforward: never expose port 18789 directly to the internet. Instead, put Cloudflare Tunnel in front of Clawdbot to handle authentication, TLS termination, and access control — all for free.
Here's how to set it up:
Step 1: Install cloudflared on Your VPS
# Debian/Ubuntu
curl -L --output cloudflared.deb \
https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
# Verify installation
cloudflared --version
Step 2: Authenticate and Create a Tunnel
# Log in to your Cloudflare account
cloudflared tunnel login
# Create a named tunnel
cloudflared tunnel create clawdbot-tunnel
Step 3: Configure the Tunnel to Route to Clawdbot
Create a configuration file at ~/.cloudflared/config.yml:
tunnel: <your-tunnel-id>
credentials-file: /root/.cloudflared/<your-tunnel-id>.json
ingress:
- hostname: clawdbot.yourdomain.com
service: http://localhost:18789
- service: http_status:404
This binds the tunnel so that Clawdbot's gateway is only reachable through your Cloudflare-managed hostname — not via the raw IP and port.
Step 4: Lock Down the Port at the Firewall Level
# Block port 18789 from all external traffic
sudo ufw deny 18789
sudo ufw allow from 127.0.0.1 to any port 18789
# Confirm rules
sudo ufw status
With this in place, port 18789 only accepts connections from localhost. The Cloudflare Tunnel process runs locally and forwards traffic inward — so the external attack surface disappears entirely.
Step 5: Enable Cloudflare Access for Authentication
In your Cloudflare Zero Trust dashboard, configure an Access Policy for the clawdbot.yourdomain.com hostname. You can gate it behind:
- Email OTP (free, no setup overhead)
- GitHub or Google SSO
- Hard-coded allowed email addresses
Now any request to your Clawdbot gateway requires a valid authenticated session through Cloudflare's identity layer before it gets anywhere near port 18789.
# Start the tunnel as a system service
sudo cloudflared service install
sudo systemctl start cloudflared
sudo systemctl enable cloudflared
Conclusion: Treat Clawdbot Like Any Unauthenticated Internal Service
The core lesson here applies beyond Clawdbot. Any tool designed for local use carries implicit assumptions about network isolation. When you move that tool to a VPS, you become responsible for enforcing those assumptions externally.
For Clawdbot specifically:
- Never run it on a VPS with port 18789 open to the public
- Always pair VPS deployments with Cloudflare Tunnel or an equivalent reverse proxy with authentication (Nginx + basic auth, Caddy with forward auth, etc.)
- Rotate your API keys immediately if you've been running an unprotected instance — assume compromise
- Audit your running browser sessions for any unexpected activity
Cloudflare Tunnel is the lowest-friction option because it's free, requires no inbound firewall rules, and plugs directly into a mature identity and access management system. There's no reason not to use it.
Clawdbot has genuine utility for AI automation workflows. But as @op7418 points out, it's a rough tool — and rough tools require careful operators. Apply the right controls, and you can use it safely. Skip them, and you're handing over the keys to anyone with a port scanner.
Source: @op7418 on X/Twitter
Tags: clawdbot security vps cloudflare-tunnel api-security devops ai-automation
Tags
Related Articles
Vercel's React Best Practices as Reusable Skill
Vercel distilled 10 years of React expertise into a skill, demonstrating how organizations should package internal best practices as reusable AI agent skills.
Building Commercial Apps with Claude Opus
Experience sharing on rapid app development using Claude Opus as a CTO, product manager, and designer combined.
AI-Powered Product Marketing with Video and Social Media
Guide on using AI to create product advertisement videos, user testimonials, and product images for social media marketing campaigns.