LobeChat CVE-2025-62505

Requires that the client can invoke the tools.search.crawlPages tRPC endpoint and supply both an arbitrary urls array and impls containing the value "naive", which routes the request to the unvalidated naive crawler fetch in packages/web-crawler. In production, a valid authenticated user token is required (limiting exploitation to authenticated users); in development mode only, authentication can be bypassed with the lobe-auth-dev-backend-api:1 header. Affected: LobeChat/@lobehub/chat <= 1.136.1. The limiting factors are the authentication requirement in production and the need for the attacker to control the target URL and impl selection; impact is maximized only where the server can reach sensitive internal services or the cloud metadata endpoint (169.254.169.254).

This is a genuinely low-priority issue despite being a network-reachable SSRF (CWE-918). Multiple signals align downward: the GitHub-assigned CVSS 3.1 vector (AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N) scores only 3.0, EPSS is 0.32% (23rd percentile), there is no CISA KEV listing (not actively exploited), and impact is limited to confidentiality (C:L) with no integrity or availability effect. The one escalating signal is that a working PoC exists in the GHSA advisory (publicly available exploit code), but POC availability is not the same as active exploitation. There is a notable internal inconsistency in the vendor/GitHub metrics versus the description: the CVSS sets PR:H and AC:H, yet the description and PoC indicate exploitation needs only a valid user token (any authenticated user, PR:L) and a single straightforward tRPC request (AC:L) - so the vector likely understates ease and overstates required privilege. Against that, real-world risk is moderated by the authentication requirement in production (the dev auth-bypass header only works in development mode), and by the limited confidentiality-only impact. The most serious realistic consequence - reaching the cloud metadata endpoint (169.254.169.254) to steal instance credentials - would be higher-impact than C:L implies, so the true confidentiality impact is deployment-dependent.

An authenticated LobeChat user (or, in a development deployment, anyone able to set the lobe-auth-dev-backend-api:1 bypass header) sends a single tools.search.crawlPages tRPC request with a urls array pointing at an internal address and impls:["naive"]. The server performs an unvalidated server-side fetch and returns the internal response body, letting the attacker read internal APIs, management ports, or cloud instance-metadata credentials. A working PoC with a curl example is published in the GHSA advisory.