GHSA-5mwj-v5jw-5c97
MEDIUMGHSA-5mwj-v5jw-5c97 is a medium-severity (CVSS 5) Improper Authentication vulnerability in @lobehub/lobehub. O3 Security confirms whether GHSA-5mwj-v5jw-5c97 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
LobeHub: Unauthenticated authentication bypass on `webapi` routes via forgeable `X-lobe-chat-auth` header
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@lobehub/lobehubnpmDescription
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]/pullPOST /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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @lobehub/lobehub | all versions | 2.1.48 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @lobehub/lobehub. 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 @lobehub/lobehub to 2.1.48 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5mwj-v5jw-5c97 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-5mwj-v5jw-5c97 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-5mwj-v5jw-5c97. 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-5mwj-v5jw-5c97 in your dependencies?
O3 detects GHSA-5mwj-v5jw-5c97 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.