DevOps

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.

February 23, 2026
6 min read
By ClawList Team

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

#security#devops#clawdbot#vulnerability#cloudflare-tunnel

Related Articles