LobeHub: Unauthenticated SSRF in `/webapi/proxy`
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
3Patches
0No 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
2News mentions
0No linked articles in our index yet.