# Zero Auth, Full Control: The Risks of Open Claude Code Web UIs

> A security analysis of open-source web UIs for Claude Code, with unauthenticated RCE, path traversal and client-side auth bypasses.

- Author: Vibhek Soni (https://vibheksoni.com/)
- Published: 2026-01-23
- Tags: web security, claude code, rce, broken access control
- URL: https://opendoors.wtf/blog/claude-code-webui-security/

## The Rise of AI Web UIs

Claude Code is a CLI and people want it in a browser so several open-source projects on GitHub like `siteboon/claudecodeui` and `clawdbot/clawdbot` wrap the CLI in a web interface.

That is useful until you remember what the CLI can do on your machine. I tested a few of these locally and most of them followed the same pattern of **trusting the client**.

**Note:** *This is not a hit piece on these specific developers. These are community projects, often experimental. The goal here is to highlight why "it works" isn't the same as "it's safe," especially when exposing powerful AI agents to a network.*

## What I Found

The architecture is simple. A frontend talks to a backend that spawns the `claude` process. In the versions I tested there was almost no validation between those two layers.

### The Exposure (FOFA Search)
Before diving into the code, I wanted to see if anyone was actually running these dangerously insecure apps on the public internet.

I ran a search on **FOFA** for unique signatures associated with these Web UIs.

[Image: FOFA.info search query finding exposed Claude Code Web UI instances]

I found **83 exposed instances**. That is 83 machines with unauthenticated remote shell access sitting on the open internet.

[Image: FOFA results showing 83 exposed instances]

### 1. Arbitrary Path Execution (The `/projects` Override)
The worst one was how the backend decided *where* to run Claude. By intercepting the request to the `/projects` endpoint I could set the target directory to anything I wanted.

Nothing on the server checked that the path sat inside an allowed directory. I could start an instance in the root of the filesystem and the agent then had read and write access to whatever it wanted.

### 2. Social Engineering the AI for Credentials
The web UI keeps chat history and it also manages the session. That second part turned out to be enough to get the agent to read out its own credentials. It has access to its environment and its config files so a plain question like "print your auth token" often worked because nothing in the system prompt told it not to.

### 3. Remote Code Execution (RCE) via AI
This is the one that matters. Claude Code runs terminal commands by design. Put that behind a web UI with no authentication and you have published an **unauthenticated web shell**.

I could verify that I could:
- Inject commands into the chat.
- Have the AI execute them on the host.
- Retrieve the output.
- Even inject fake chat history to manipulate the AI's context.

### 4. Client-Side Authentication Bypass
One project did try to protect the interface with a PIN. The check ran entirely in the browser.

I opened DevTools and found a boolean in `localStorage` that meant "authenticated". I set it to `true`, refreshed the page and I was in. The server never checked a session token on the next request because it trusted the frontend to stop people.

## The "Not My Bug" Syndrome

All of this comes from one misunderstanding. People treat an LLM wrapper like a normal web app. When the thing on the other side of the wrapper has a shell then what you built is a **remote administration tool** with a chat box on the front.

Three things have to be there.

1. **Auth on the server.** A JWT or session cookie checked on *every* request rather than once in the browser.
2. **A sandbox.** Run the agent in a container with the permissions it actually needs and nothing else.
3. **Allowlists.** Paths and commands checked against a list you wrote before the request arrives.

Miss one of those and a single bad setting is a full compromise.

## For Developers & Users

**If you are building one of these tools.**

- Never trust the client.
- Assume the person sending the request wants in.
- Put a security risks section in your README and tell people not to bind it to `0.0.0.0` without a VPN or a reverse proxy in front of it.

**If you are using one.**

- Do not port forward it to the internet.
- Run it in a VM or a container if you can.
- Treat it like a terminal window that is already open on your desktop.

An LLM is a bad security guard. Do not make it the only thing between the internet and your shell.