CVE-2024-32964: Lobehub Lobe Chat SSRF Vulnerability

CVE-2024-32964 Overview

Lobe Chat is an open-source chatbot framework supporting speech synthesis, multimodal inputs, and an extensible Function Call plugin system. Versions prior to 0.150.6 contain a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in the /api/proxy endpoint. The endpoint accepts attacker-controlled URLs and forwards requests without validating whether the destination resolves to an internal address. Unauthenticated attackers can use the proxy to reach intranet services, query cloud metadata endpoints, and exfiltrate sensitive information.

Critical Impact

Unauthenticated SSRF allows attackers to pivot into internal networks, access metadata services, and disclose sensitive data through the Lobe Chat proxy endpoint.

Affected Products

• Lobehub Lobe Chat versions prior to 0.150.6
• Self-hosted Lobe Chat deployments exposing /api/proxy
• Cloud-deployed Lobe Chat instances on Vercel, Docker, or similar runtimes

Discovery Timeline

• 2024-05-14 - CVE-2024-32964 published to the National Vulnerability Database
• 2024-05-14 - GitHub Security Advisory GHSA-mxhq-xw3g-rphc published by Lobehub
• 2025-09-30 - Last updated in the NVD database

Technical Details for CVE-2024-32964

Vulnerability Analysis

The vulnerability resides in src/app/api/proxy/route.ts, which exposes a POST endpoint that forwards arbitrary user-supplied URLs. The original implementation accepted the request body as raw text and passed it directly into a fetch call. No authentication, host allowlist, or address validation was applied. An attacker can submit any URL — including http://127.0.0.1, http://169.254.169.254/latest/meta-data/, or internal hostnames — and receive the response through the proxy.

Because the route ran on the edge runtime, it had network reachability that could include private network ranges in self-hosted deployments. The response is returned to the caller, enabling both blind and reflective SSRF exploitation. Attackers can enumerate internal services, query cloud metadata APIs for IAM credentials, and read responses from unauthenticated intranet web interfaces.

Root Cause

The root cause is missing destination validation. The handler treated the request body as a trusted URL string and called fetch() without resolving the hostname and verifying it against private address ranges defined in RFC 1918, RFC 6598, loopback, and link-local space.

Attack Vector

Exploitation requires only network access to a vulnerable Lobe Chat instance. An attacker sends a POST request to /api/proxy with the target URL in the body. The server resolves the hostname, issues the request, and returns the response. No authentication is required.

// Patch from src/app/api/proxy/route.ts
-export const runtime = 'edge';
+import { isPrivate } from 'ip';
+import { NextResponse } from 'next/server';
+import dns from 'node:dns';
+import { promisify } from 'node:util';
+
+const lookupAsync = promisify(dns.lookup);
+
+export const runtime = 'nodejs';
 
 /**
  * just for a proxy
  */
 export const POST = async (req: Request) => {
-  const url = await req.text();
+  const url = new URL(await req.text());
+  let address;
+
+  try {
+    const lookupResult = await lookupAsync(url.hostname);
+    address = lookupResult.address;
+  } catch (err) {
+    console.error(`${url.hostname} DNS parser error:`, err);
+
+    return NextResponse.json({ error: 'DNS parser error' }, { status: 504 });
+  }
+
+  const isInternalHost = isPrivate(address);
+
+  if (isInternalHost)
// Source: https://github.com/lobehub/lobe-chat/commit/465665a735556669ee30446c7ea9049a20cc7c37

The patch switches the runtime to nodejs, resolves the hostname via dns.lookup, and rejects requests whose resolved address is in private space using the ip.isPrivate check.

Detection Methods for CVE-2024-32964

Indicators of Compromise

• POST requests to /api/proxy with body values referencing loopback addresses (127.0.0.1, localhost) or RFC 1918 ranges
• Requests to /api/proxy containing cloud metadata hostnames such as 169.254.169.254 or metadata.google.internal
• Outbound traffic from the Lobe Chat application toward internal services that the application does not normally contact
• Unexpected DNS queries originating from the Lobe Chat host for internal hostnames

Detection Strategies

• Inspect web server and reverse proxy access logs for POST traffic to /api/proxy and correlate body contents against private IP literals or internal DNS names
• Deploy a Web Application Firewall (WAF) rule that blocks /api/proxy request bodies containing private CIDR ranges, link-local addresses, and metadata endpoints
• Run version inventory checks against deployed Lobe Chat containers to flag any image tagged below 0.150.6

Monitoring Recommendations

• Alert on egress connections from the Lobe Chat process to internal subnets, 169.254.0.0/16, and other non-business destinations
• Capture and retain full request bodies for /api/proxy to support post-incident analysis
• Monitor for credential use anomalies on any cloud IAM role attached to the host running Lobe Chat

How to Mitigate CVE-2024-32964

Immediate Actions Required

• Upgrade Lobe Chat to version 0.150.6 or later in all production and staging environments
• Restrict network egress from Lobe Chat containers so they cannot reach internal subnets or cloud metadata endpoints
• Place the /api/proxy route behind authentication or remove it if the proxy functionality is not required
• Rotate any cloud credentials or API keys reachable from the Lobe Chat host as a precaution

Patch Information

The fix is delivered in commit 465665a and described in GitHub Security Advisory GHSA-mxhq-xw3g-rphc. The patch resolves the supplied hostname via DNS and rejects requests whose resolved address falls inside a private range using the ip.isPrivate helper.

Workarounds

• Block public access to /api/proxy at the reverse proxy or ingress layer until the upgrade is applied
• Use network policies, security groups, or IMDSv2 to deny outbound access from the Lobe Chat workload to 169.254.169.254 and other metadata endpoints
• Deploy WAF signatures that reject /api/proxy bodies containing private addresses or internal hostnames

# Example NGINX block to deny external access to /api/proxy
location = /api/proxy {
    allow 10.0.0.0/8;      # restrict to trusted management network
    deny all;
    proxy_pass http://lobe_chat_upstream;
}

# Example AWS metadata egress block via iptables
iptables -A OUTPUT -d 169.254.169.254 -j DROP