GHSA-5MWJ-V5JW-5C97
Vulnerability from github – Published: 2026-04-08 15:04 – Updated: 2026-04-09 14:28Summary
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:
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:
- access protected webapi routes without a valid session
- spend the deployment's server-side model provider credentials when env keys like OPENAI_API_KEY are configured
- impersonate another user's userId for routes that load per-user provider configuration
- 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:
- the auth header is only obfuscated, not authenticated
- the obfuscation key is hardcoded and recoverable from the repository
- the decoded apiKey field is treated as sufficient authentication even though it is never validated in this code path
- Suggested Remediation
- Stop treating X-lobe-chat-auth as an authentication token.
- Remove the apiKey truthiness check as an auth decision.
- Require a real server-validated session, OIDC token, or validated API key for all protected webapi routes.
- If a client payload is still needed, sign it server-side with an HMAC or replace it with a normal session-bound backend lookup.
- 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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.1.47"
},
"package": {
"ecosystem": "npm",
"name": "@lobehub/lobehub"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.48"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39411"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T15:04:30Z",
"nvd_published_at": "2026-04-08T20:16:25Z",
"severity": "MODERATE"
},
"details": "# Summary\n\nThe `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.\n\nAffected routes include:\n- `POST /webapi/chat/[provider]`\n- `GET /webapi/models/[provider]`\n- `POST /webapi/models/[provider]/pull`\n- `POST /webapi/create-image/comfyui`\n\n## Details\n\nThe frontend creates `X-lobe-chat-auth` by XOR-obfuscating JSON with the static key `LobeHub \u00b7 LobeHub`, and the backend reverses that operation and treats the decoded JSON as trusted authentication data.\n\nThe backend then accepts any truthy `apiKey` field in that decoded payload as sufficient authentication. No real API key validation is performed in this path.\n\nAs a result, an unauthenticated attacker can forge payloads such as:\n\n```json\n{\"apiKey\":\"x\"} \n```\n\nor \n\n``` {\"userId\":\"victim-user-123\",\"apiKey\":\"x\"} ```\n\nand access webapi routes as an authenticated user.\n\nConfirmed PoC\nThe following forged header was generated directly from the published XOR key using payload {\"apiKey\":\"x\"}:\n\n\n``` X-lobe-chat-auth: N00DFSE+B1ngjQI0TR8= ```\n\nThat header decodes server-side to:\n\n``` {\"apiKey\":\"x\"}```\n\nA simple request is:\n\n``` curl \u0027https://TARGET/webapi/models/openai\u0027 \\\n -H \u0027X-lobe-chat-auth: N00DFSE+B1ngjQI0TR8=\u0027 ``` \n\nIf the deployment has OPENAI_API_KEY configured, the request should succeed without a real login and return the provider model list.\n\nA forged impersonation payload also works conceptually:\n\n``` {\"userId\":\"victim-user-123\",\"apiKey\":\"x\"} ``` \n\n### Impact\nThis is an unauthenticated authentication bypass.\n\nAn attacker can:\n\n1. access protected webapi routes without a valid session\n2. spend the deployment\u0027s server-side model provider credentials when env keys like OPENAI_API_KEY are configured\n3. impersonate another user\u0027s userId for routes that load per-user provider configuration\n4. invoke privileged backend model operations such as chat, model listing, model pulls, and ComfyUI image generation\n\n### Root Cause\nThe core issue is trusting unsigned client-supplied auth data:\n\n1. the auth header is only obfuscated, not authenticated\n2. the obfuscation key is hardcoded and recoverable from the repository\n3. the decoded apiKey field is treated as sufficient authentication even though it is never validated in this code path\n4. Suggested Remediation\n5. Stop treating X-lobe-chat-auth as an authentication token.\n6. Remove the apiKey truthiness check as an auth decision.\n7. Require a real server-validated session, OIDC token, or validated API key for all protected webapi routes.\n8. If a client payload is still needed, sign it server-side with an HMAC or replace it with a normal session-bound backend lookup.\n9. Affected Products\n\nEcosystem: npm\n\nPackage name: @lobehub/lobehub\nAffected versions: \u003c= 2.1.47\nPatched versions: 2.1.48\n\nSeverity\nModerate\nVector String\nCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L\n\nWeaknesses\nCWE-287: Improper Authentication\nCWE-345: Insufficient Verification of Data Authenticity\nCWE-290: Authentication Bypass by Spoofing",
"id": "GHSA-5mwj-v5jw-5c97",
"modified": "2026-04-09T14:28:56Z",
"published": "2026-04-08T15:04:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lobehub/lobehub/security/advisories/GHSA-5mwj-v5jw-5c97"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39411"
},
{
"type": "WEB",
"url": "https://github.com/lobehub/lobehub/pull/13535"
},
{
"type": "WEB",
"url": "https://github.com/lobehub/lobehub/commit/3327b293d66c013f076cbc16cdbd05a61a3d0428"
},
{
"type": "PACKAGE",
"url": "https://github.com/lobehub/lobehub"
},
{
"type": "WEB",
"url": "https://github.com/lobehub/lobehub/releases/tag/v2.1.48"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "LobeHub: Unauthenticated authentication bypass on `webapi` routes via forgeable `X-lobe-chat-auth` header"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.