CVE-2026-39411

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:

{"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:

  -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

The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.

CVE-2026-39411 has a CVSS score of 5.0 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.1.48); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-39411? CVE-2026-39411 is a medium-severity improper authentication vulnerability in @lobehub/lobehub (npm), affecting versions <= 2.1.47. It is fixed in 2.1.48. The application does not adequately verify the identity of a user, device, or process before granting access.
2. How severe is CVE-2026-39411? CVE-2026-39411 has a CVSS score of 5.0 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @lobehub/lobehub are affected by CVE-2026-39411? @lobehub/lobehub (npm) versions <= 2.1.47 is affected.
4. Is there a fix for CVE-2026-39411? Yes. CVE-2026-39411 is fixed in 2.1.48. Upgrade to this version or later.
5. Is CVE-2026-39411 exploitable, and should I be worried? Whether CVE-2026-39411 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-39411 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-39411? Upgrade @lobehub/lobehub to 2.1.48 or later.