| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| @lobehub/chat | < 1.136.2 | 1.136.2 |
Vulnerability Overview
When the client sends an arbitrary URL array and impl: ["naive"] to the tRPC endpoint tools.search.crawlPages, the server issues outbound HTTP requests directly to those URLs. There is no defensive logic that restricts or validates requests to internal networks (127.0.0.1, localhost, private ranges) or metadata endpoints (169.254.169.254).
Flow: client input (urls, impls) → service invocation in the tRPC router → the service passes the URLs to Crawler.crawl → the Crawler prioritizes the user-specified impls (naive) → the naive implementation performs a server-side fetch(url) as-is (SSRF) → the server collects responses from internal resources.
In the dev environment, authentication can be bypassed using the lobe-auth-dev-backend-api: 1 header (production requires a valid token). In the PoC, this was used to successfully retrieve the internal API at localhost:8889 from the server side.
Vulnerable Code
PoC Description
In dev mode, we made a single tRPC call using the auth-bypass header lobe-auth-dev-backend-api: 1. Since tRPC requires the body to be in the form {"json": { ... }}, we placed urls and impls: ["naive"] inside json to induce the server to request the internal URL (http://localhost:8889/internel-api).
The response follows tRPC’s wrapping structure, so the actual body of the internal API is included as a string (JSON string) at result.data.json.results[0].data.content. We post-process it with jq for readability.
curl Example
curl -sS -X POST 'http://localhost:3010/trpc/tools/search.crawlPages' \
-H 'Content-Type: application/json' \
-H 'lobe-auth-dev-backend-api: 1' \
--data '{"json":{"urls":["http://localhost:8889/internal-api"],"impls":["naive"]}}' | jq -r '.result.data.json.results[0].data.content' | jq .
Since the server performs outbound requests to internal networks, localhost, and metadata endpoints, an attacker can abuse the server’s network position to access internal resources (internal APIs, management ports, cloud metadata, etc.).
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャンAs a result, this can lead to exposure of internal system information, leakage of authentication tokens/secret keys (e.g., IMDSv1/v2), misuse of internal admin interfaces, and provide a foothold for further lateral movement.
By leveraging user-supplied impls to force the unfiltered naive implementation, SSRF defenses—such as blocking private/metadata IPs, DNS re-validation/re-resolution, and redirect restrictions—can be bypassed.