VYPR
\n```\n\nThe attacker's server at `/inject?x=` responds with `Set-Cookie: __session=KNOWN_VALUE; Path=/; Domain=lobehub.com; Secure; HttpOnly`. The proxy reflects this header and the victim's browser stores the cookie.\n\n## Impact\n\nThe proxy is fully unauthenticated and returns the complete response from any external URL. I confirmed the following on app.lobehub.com:\n\nAn attacker can inject authentication cookies (`__session`, `__clerk_db_jwt`, `__client_uat`) on the `lobehub.com` domain by chaining CSRF with the proxy's reflected `Set-Cookie` headers. If LobeHub uses Clerk for session management, this is a session fixation vector — the attacker sets a known session value before the victim logs in, then uses that same value to access the victim's session.\n\nThe proxy also leaks Vercel infrastructure details. The `Traceparent` and `X-Vercel-Id` headers from internal request tracing appear in every proxied response. The server's egress IP is exposed. Vercel Edge Config and the Vercel API are both reachable through the proxy (they return auth errors, not SSRF blocks), which means the proxy reaches Vercel's management plane.\n\nThe endpoint has no rate limiting. An attacker can use LobeHub's infrastructure as an anonymous proxy for scanning, phishing, or abusing IP-based trust relationships with third-party services.\n\n## Recommended Fix\n\nAdd `checkAuth()` to the proxy route, matching every other webapi route:\n\n```diff\n- export const POST = async (req: Request) => {\n+ export const POST = checkAuth(async (req, { userId }) => {\n```\n\nIf the proxy is only needed for client-side URL previews, consider removing the endpoint entirely and handling previews in the browser.","additionalType":"https://schema.org/SoftwareApplication","sameAs":["https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-54157"]},"keywords":"CVE-2026-54157, critical, CWE-918, Lobehub Lobehub, Lobehub Lobehub","mentions":[{"@type":"SoftwareApplication","name":"Lobehub","applicationCategory":"SecurityApplication","publisher":{"@type":"Organization","name":"Lobehub"}},{"@type":"SoftwareApplication","name":"Lobehub","applicationCategory":"SecurityApplication","publisher":{"@type":"Organization","name":"Lobehub"}}],"isAccessibleForFree":true},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://portal.vyprsec.ai/"},{"@type":"ListItem","position":2,"name":"CVEs","item":"https://portal.vyprsec.ai/cves"},{"@type":"ListItem","position":3,"name":"CVE-2026-54157","item":"https://portal.vyprsec.ai/cves/CVE-2026-54157"}]}]}
Critical severity9.0GHSA Advisory· Published Jun 16, 2026

LobeHub: Unauthenticated SSRF in `/webapi/proxy`

CVE-2026-54157

Description

CVE-2026-54157: Unauthenticated SSRF in LobeHub's /webapi/proxy endpoint allows arbitrary outbound requests and session cookie injection.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

CVE-2026-54157: Unauthenticated SSRF in LobeHub's /webapi/proxy endpoint allows arbitrary outbound requests and session cookie injection.

Vulnerability

The /webapi/proxy endpoint in LobeHub (file src/app/(backend)/webapi/proxy/route.ts) accepts a URL in the POST body and fetches it server-side via ssrfSafeFetch() without any authentication check [1][2]. This endpoint is the only webapi route missing the checkAuth() wrapper; all other webapi routes (/webapi/chat/*, /webapi/models/*, /webapi/create-image/*) require authentication. The Next.js middleware also skips /webapi/ routes by calling NextResponse.next(), so neither middleware nor the route handler performs authentication. The issue affects all versions of LobeHub prior to the security patch for this CVE. This is a regression of the same proxy code that was patched in CVE-2024-32964, but the /webapi/proxy route was never secured [1][2].

Exploitation

An attacker needs no authentication, cookies, or tokens. To fetch an external URL, the attacker sends a POST request with Content-Type: text/plain;charset=UTF-8 and the target URL as the body to https://app.lobehub.com/webapi/proxy. The server returns the full response body, as demonstrated by fetching https://httpbin.org/ip which revealed LobeHub’s Vercel serverless function IP (3.14.141.44) [1][2]. To inject cookies on the lobehub.com domain, the attacker uses the same endpoint with a URL that reflects Set-Cookie headers (e.g., httpbin.org/response-headers?Set-Cookie=...). The server’s response headers include the attacker‑controlled set-cookie header, allowing arbitrary cookie injection [1][2].

Impact

Successful exploitation enables Server‑Side Request Forgery (CWE-918). An attacker can make arbitrary outbound HTTP requests from LobeHub’s infrastructure, potentially accessing internal services, leaking Vercel deployment details, and probing internal networks. Additionally, by injecting Set-Cookie headers into the proxy’s response, an attacker can set arbitrary cookies on the lobehub.com domain, which could lead to session hijacking or other client‑side attacks [1][2].

Mitigation

No fixed version or patch has been released as of the publication date of this advisory. Users are advised to monitor the vendor’s security advisories for an update. In the absence of a patch, administrators may consider implementing a web application firewall (WAF) rule to block requests to /webapi/proxy or to require authentication for that endpoint. The endpoint is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog as of the publication date [1][2].

AI Insight generated on Jun 16, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

3

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"The `/webapi/proxy` route handler calls `ssrfSafeFetch()` without first invoking `checkAuth()`, allowing unauthenticated server-side request forwarding."

Attack vector

An attacker sends a POST request to `/webapi/proxy` with a target URL in the body; the server fetches that URL and returns the full response, enabling arbitrary outbound requests from LobeHub's infrastructure [CWE-918]. The proxy reflects upstream `Set-Cookie` headers (only stripping `Content-Encoding` and `Content-Length`), so an attacker can inject authentication cookies such as `__session` and `__clerk_db_jwt` on the `lobehub.com` domain [ref_id=1]. This can be chained with a CSRF form — a victim visiting an attacker's page triggers the browser to submit a form to the proxy, which fetches the attacker's server; the attacker's server returns a `Set-Cookie` header, and the proxy reflects it to the victim's browser, setting a known session value on `lobehub.com` [ref_id=1][ref_id=2].

Affected code

The vulnerable endpoint is `POST /webapi/proxy` in the file `src/app/(backend)/webapi/proxy/route.ts` [ref_id=1]. The route handler accepts a URL from the request body and passes it to `ssrfSafeFetch()` without calling `checkAuth()` first. Every other webapi route wraps the handler in `checkAuth()`, but the proxy does not, and the Next.js middleware also skips `/webapi/` routes entirely [ref_id=1][ref_id=2].

What the fix does

The recommended fix is to add `checkAuth()` to the proxy route, matching every other webapi route — changing `export const POST = async (req: Request) => {` to `export const POST = checkAuth(async (req, { userId }) => {` [ref_id=1][ref_id=2]. This ensures the handler is only callable by authenticated users, just like `/webapi/chat/*`, `/webapi/models/*`, and `/webapi/create-image/*`. The advisory also suggests considering removal of the endpoint entirely if the proxy is only needed for client-side URL previews [ref_id=1].

Preconditions

  • networkPOST /webapi/proxy endpoint is publicly accessible without authentication
  • inputTarget URL is supplied in the request body; no auth token, cookie, or session required

Generated on Jun 16, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

2

News mentions

0

No linked articles in our index yet.