CVE-2026-39411: LobeChat: auth bypass via forged XOR obfuscated header

Published April 8, 2026

CISO Take

LobeChat's webapi authentication layer can be bypassed by any network attacker using a single forged HTTP header, constructed from a hardcoded XOR key that is publicly available in the repository — a working curl one-liner PoC encoding {"apiKey":"x"} is already published. For self-hosted deployments with server-side AI provider credentials (OPENAI_API_KEY, Anthropic keys, etc.), this means an unauthenticated adversary can consume your AI API budget, invoke model pulls and ComfyUI image generation, and impersonate arbitrary users via spoofed userId fields — all without a valid session. With 2,703 downstream npm dependents and trivial exploitation requiring zero AI expertise, the blast radius across the self-hosted AI chat ecosystem is significant despite the medium CVSS 5.0 rating, which appears to understate real-world risk given the confirmed PoC. Upgrade to @lobehub/lobehub v2.1.48 immediately, rotate all configured AI provider API keys, and deploy WAF detection for the known-forged header value N00DFSE+B1ngjQI0TR8=.

Sources: GitHub Advisory NVD ATLAS

Risk Assessment

The CVSS 5.0 Medium score materially understates operational risk for self-hosted deployments with configured AI provider keys. Exploitation is trivial — a published single curl command bypasses authentication with the pre-computed header; no prior privileges are realistically required and the PR:L CVSS rating is difficult to reconcile with the PoC. Any deployment with OPENAI_API_KEY or equivalent environment-level credentials faces direct financial exposure through unauthorized API consumption. The 2,703 downstream npm dependents amplify exposure significantly across the self-hosted AI chat ecosystem. Effective risk should be treated as HIGH for any organization running self-hosted LobeChat with server-side provider credentials configured.

Affected Systems

Package	Ecosystem	Vulnerable Range	Patched
@lobehub/lobehub	npm	<= 2.1.47	`2.1.48`
10.8K 2.7K dependents Pushed 4d ago 100% patched ~0d to patch Full package profile →

Do you use @lobehub/lobehub? You're affected.

Severity & Risk

CVSS 3.1

5.0 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

Recommended Action

Patch immediately: upgrade @lobehub/lobehub to v2.1.48 (commit 3327b293d66c013f076cbc16cdbd05a61a3d0428 removes the insecure X-lobe-chat-auth trust path).
Treat all AI provider API keys configured in LobeChat environment variables as compromised — rotate OPENAI_API_KEY and equivalent credentials now, regardless of observed abuse.
WAF/perimeter: create detection rules for any request containing the X-lobe-chat-auth header, alerting on the known PoC value N00DFSE+B1ngjQI0TR8= as an immediate indicator of exploitation.
Audit AI provider billing dashboards for anomalous API consumption in the period prior to patching to assess exposure window.
If immediate patching is blocked by change control, apply a network-layer compensating control: restrict /webapi/* routes to authenticated internal networks only.

Classification

Auth Bypass Data Extraction DoS API Inference AML.T0012 - Valid Accounts AML.T0034 - Cost Harvesting AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0091.000 - Application Access Token

Compliance Impact

This CVE is relevant to:

EU AI Act

Article 9 - Risk Management System

ISO 42001

A.6.2.1 - Information Access Restriction

NIST AI RMF

GOVERN-1.7 - Processes and procedures for AI risk management

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure LLM10:2025 - Unbounded Consumption

Technical Details

NVD Description

# Summary The `webapi` authentication layer trusts a client-controlled `X-lobe-chat-auth` header that is only XOR-obfuscated, not signed or otherwise authenticated. Because the XOR key is hardcoded in the repository, an attacker can forge arbitrary auth payloads and bypass authentication on protected `webapi` routes. Affected routes include: - `POST /webapi/chat/[provider]` - `GET /webapi/models/[provider]` - `POST /webapi/models/[provider]/pull` - `POST /webapi/create-image/comfyui` ## Details The frontend creates `X-lobe-chat-auth` by XOR-obfuscating JSON with the static key `LobeHub · LobeHub`, and the backend reverses that operation and treats the decoded JSON as trusted authentication data. The backend then accepts any truthy `apiKey` field in that decoded payload as sufficient authentication. No real API key validation is performed in this path. As a result, an unauthenticated attacker can forge payloads such as: ```json {"apiKey":"x"} ``` or ``` {"userId":"victim-user-123","apiKey":"x"} ``` and access webapi routes as an authenticated user. Confirmed PoC The following forged header was generated directly from the published XOR key using payload {"apiKey":"x"}: ``` X-lobe-chat-auth: N00DFSE+B1ngjQI0TR8= ``` That header decodes server-side to: ``` {"apiKey":"x"}``` A simple request is: ``` curl 'https://TARGET/webapi/models/openai' \ -H 'X-lobe-chat-auth: N00DFSE+B1ngjQI0TR8=' ``` If the deployment has OPENAI_API_KEY configured, the request should succeed without a real login and return the provider model list. A forged impersonation payload also works conceptually: ``` {"userId":"victim-user-123","apiKey":"x"} ``` ### Impact This is an unauthenticated authentication bypass. An attacker can: 1. access protected webapi routes without a valid session 2. spend the deployment's server-side model provider credentials when env keys like OPENAI_API_KEY are configured 3. impersonate another user's userId for routes that load per-user provider configuration 4. invoke privileged backend model operations such as chat, model listing, model pulls, and ComfyUI image generation ### Root Cause The core issue is trusting unsigned client-supplied auth data: 1. the auth header is only obfuscated, not authenticated 2. the obfuscation key is hardcoded and recoverable from the repository 3. the decoded apiKey field is treated as sufficient authentication even though it is never validated in this code path 4. Suggested Remediation 5. Stop treating X-lobe-chat-auth as an authentication token. 6. Remove the apiKey truthiness check as an auth decision. 7. Require a real server-validated session, OIDC token, or validated API key for all protected webapi routes. 8. If a client payload is still needed, sign it server-side with an HMAC or replace it with a normal session-bound backend lookup. 9. Affected Products Ecosystem: npm Package name: @lobehub/lobehub Affected versions: <= 2.1.47 Patched versions: 2.1.48 Severity Moderate Vector String CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L Weaknesses CWE-287: Improper Authentication CWE-345: Insufficient Verification of Data Authenticity CWE-290: Authentication Bypass by Spoofing

Exploitation Scenario

An adversary identifies a self-hosted LobeChat instance via Shodan, certificate transparency logs, or direct targeting of an organization known to use LobeChat. Using the hardcoded XOR key (`LobeHub · LobeHub`) from the public repository, they generate a forged X-lobe-chat-auth header encoding {"apiKey":"x"} — or simply copy the pre-computed value N00DFSE+B1ngjQI0TR8= directly from the advisory. A single unauthenticated GET to /webapi/models/openai confirms OPENAI_API_KEY is configured. The adversary then scripts continuous POST requests to /webapi/chat/openai with resource-intensive prompts, burning the victim's API quota and generating financial charges. In a secondary move, the attacker enumerates user IDs via application-level enumeration, forges {"userId":"victim-id","apiKey":"x"}, and accesses per-user provider configuration routes to harvest individually-stored API keys or exfiltrate conversation metadata.