Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The file upload feature in Knowledge Base File Upload does not validate the integrity of the upload request, allowing users to intercept and modify the request parameters. As a result, it is possible to create arbitrary files in abnormal or unintended paths. In addition, since lobechat.com relies on the size parameter from the request to calculate file usage, an attacker can manipulate this value to misrepresent the actual file size, such as uploading a 1 GB file while reporting it as 10 MB, or falsely declaring a 10 MB file as a 1 GB file. Details After entering the Knowledge Base, click the file upload option and upload any file. At this point, use a tool such as Burp Suite to intercept and inspect the request sent to POST /trpc/lambda/file.createFile?batch=1 (the request packet is shown in the image below). By modifying the name and size fields in this request, it is possible to bypass the maximum upload size enforced by LobeChat’s monthly subscription plan and upload…
Recommended action: Upgrade to 1.143.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Description --- 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…
Recommended action: Upgrade to 1.136.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
--- Vulnerability Overview The project's OIDC redirect handling logic constructs the host and protocol of the final redirect URL based on the X-Forwarded-Host or Host headers and the X-Forwarded-Proto value. In deployments where a reverse proxy forwards client-supplied X-Forwarded- headers to the origin as-is, or where the origin trusts them without validation, an attacker can inject an arbitrary host and trigger an open redirect that sends users to a malicious domain. Vulnerable Code Analysis https://github.com/lobehub/lobe-chat/blob/aa841a3879c30142720485182ad62aa0dbd74edc/src/app/(backend)/oidc/consent/route.ts#L113-L127 PoC --- curl Example <img width="1504" height="304" alt="image" src="https://github.com/user-attachments/assets/b71d937d-7be2-49db-8f3d-e07371912800" / Impact --- - It can force users to redirect to untrusted external domains, leading to subsequent attacks such as phishing, credential harvesting, and session fixation. - It can disrupt the OAuth/OIDC…
Recommended action: Upgrade to 1.130.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
We identified a cross-site scripting (XSS) vulnerability when handling chat message in lobe-chat that can be escalated to remote code execution on the user’s machine. Any party capable of injecting content into chat messages, such as hosting a malicious page for prompt injection, operating a compromised MCP server, or leveraging tool integrations, can exploit this vulnerability. Vulnerability Details XSS via SVG Rendering In lobe-chat, when the response from the server is like <lobeArtifact identifier="ai-new-interpretation" ... , it will be rendered with the lobeArtifact node, instead of the plain text. https://github.com/lobehub/lobe-chat/blob/0a1dcf943ea294e35acbe57d07f7974efede8e2e/src/features/Conversation/components/MarkdownElements/LobeArtifact/rehypePlugin.ts#L50-L68 https://github.com/lobehub/lobe-chat/blob/0a1dcf943ea294e35acbe57d07f7974efede8e2e/src/features/Conversation/components/MarkdownElements/LobeArtifact/index.ts#L7-L11…
Recommended action: Upgrade to 1.129.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
lobe-chat before 1.19.13 has an unauthorized ssrf vulnerability. An attacker can construct malicious requests to cause SSRF without logging in, attack intranet services, and leak sensitive information. Details visit https://chat-preview.lobehub.com/ click settings - llm - openai fill the OpenAI API Key you like fill the proxy address that you want to attack (e.g. a domain that resolved to a local ip addr like 127.0.0.1.xip.io) (the address will concat the path "/chat/completions" which can be bypassed with sharp like "http://172.23.0.1:8000/#") then lobe will echo the ssrf result The jwt token header X-Lobe-Chat-Auth strored proxy address and OpenAI API Key, you can modify it to scan internal network in your target lobe-web. PoC Impact SSRF, All users will be impacted.
Recommended action: Upgrade to 1.19.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SSRF protection implemented in https://github.com/lobehub/lobe-chat/blob/main/src/app/api/proxy/route.ts does not consider redirect and could be bypassed when attacker provides external malicious url which redirects to internal resources like private network or loopback address. PoC 1. Run lobe-chat in docker container. In my setup lobe-chat runs on 0.0.0.0:3210; 2. Create file dummy-server.js with the following content: And run as an example server inside of container [1] (or in containers private network). 3. Run in terminal to perform request to lobe-chat instance from [1] where body contains url of server which redirects to internal network (in my case it redirects according url parameter). 4. Observe in output of [2] 5. Attacker is able to perform SSRF attacks against lobe-chat despite https://github.com/lobehub/lobe-chat/blob/main/src/app/api/proxy/route.ts#L26 check. Fix recommendations: 1. Disable redirects - lobe-chat should consider explicitly disable redirects. 2.…
Recommended action: Upgrade to 1.19.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If an attacker can successfully authenticate through SSO/Access Code, they can obtain the real backend API Key by modifying the base URL to their own attack URL on the frontend and setting up a server-side request. Details The attack process is described above. PoC Frontend: 1. Pass basic authentication (SSO/Access Code). 2. Set the Base URL to a private attack address. 3. Configure the request method to be a server-side request. 4. At the self-set attack address, retrieve the API Key information from the request headers. Backend: 1. The LobeChat version allows setting the Base URL. 2. There is no outbound traffic whitelist. Impact All community version LobeChat users using SSO/Access Code authentication, tested on version 0.162.13.
Recommended action: Upgrade to 0.162.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The latest version of lobe-chat(by now v0.141.2) has an unauthorized ssrf vulnerability. An attacker can construct malicious requests to cause SSRF without logging in, attack intranet services, and leak sensitive information. Details visit https://chat-preview.lobehub.com/settings/agent you can attack all internal services by /api/proxy and get the echo in http response :) PoC Impact SSRF ,All users will be impacted.
Recommended action: Upgrade to 0.150.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the application is password-protected (deployed with the ACCESSCODE option), it is possible to access plugins without proper authorization (without password). Proof-of-Concept: Let’s suppose that application has been deployed with following command: Due to the utilization of the ACCESSCODE, access to the chat is possible only after entering the password: However, it is possible to interact with chat plugins without entering the ACCESSCODE. Example HTTP request: HTTP response: Remediation: Verify the ACCESSCODE for HTTP requests to the /api/plugin/: route. Impact: Unauthorized access to plugins.
Recommended action: Upgrade to 0.122.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.