CVE-2026-54033: LibreChat SSRF Vulnerability via Custom API Endpoint Configuration

Technical summary

CVE-2026-54033 is an SSRF vulnerability (CWE-918) in LibreChat's baseURL parameter handling. When a user configures a custom OpenAI-compatible API endpoint, the application constructs HTTP requests to the specified URL without performing validation checks. Specifically, the code does not implement: private IP address filtering (RFC 1918 ranges), scheme restrictions, DNS pinning, or localhost detection. An authenticated attacker can set baseURL to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), cloud metadata endpoints (169.254.169.254), localhost (127.0.0.1), or internal hostnames. The application will then attempt to reach these addresses on behalf of the server, potentially exposing internal service responses or triggering actions on protected systems.

Business impact

The vulnerability creates a lateral movement and reconnaissance pathway for accounts that have legitimate LibreChat access. A compromised user credential or insider can abuse the custom endpoint feature to map internal network topology, probe internal APIs, access database management interfaces, or trigger actions in backend systems. In cloud environments, this could expose cloud metadata endpoints containing IAM credentials. For self-hosted deployments, it enables attackers to bypass network segmentation controls. The impact is limited to users with authentication; however, if LibreChat is deployed in an environment with weak credential hygiene or shared accounts, the risk surface widens significantly.

Affected systems

LibreChat versions prior to 0.8.4-rc1 are affected. The vulnerability requires authentication, so only users with valid LibreChat accounts can exploit it. Self-hosted LibreChat instances where network isolation between the application server and internal services is incomplete face the highest risk. Hosted or SaaS LibreChat deployments may have lower exposure if the application runs in an isolated network segment with restricted outbound access.

Exploitability

Exploitability is moderate. The vulnerability requires valid authentication and legitimate access to LibreChat's settings UI to configure a custom endpoint. No special tools or unusual interaction patterns are required; the attacker simply enters a malicious URL in the configuration form. The HTTP requests are made synchronously by the server, so responses or error messages may leak information about internal systems. Detection by network monitoring is possible if outbound traffic policies are in place, but many deployments lack internal egress controls. The attack is deterministic and does not depend on race conditions, timing, or user interaction.

Remediation

Upgrade LibreChat to version 0.8.4-rc1 or later. This version includes SSRF validation logic that blocks requests to private IP ranges, localhost, and other non-routable addresses. After patching, review any custom API endpoints that were previously configured to ensure they were not set to internal addresses by mistake or malice. Consider implementing network egress policies that restrict outbound HTTP/HTTPS traffic from the LibreChat server to approved external endpoints only.

Patch guidance

Apply the upgrade to 0.8.4-rc1 as soon as it reaches stable release (verify against official LibreChat release channels). If running LibreChat in a container, pull the latest image and redeploy. If running from source, pull the latest commit and rebuild. Test the patch in a non-production environment first to verify that legitimate custom endpoints still function. After patching, audit the LibreChat configuration database for any baseURL entries pointing to internal addresses (10.*, 172.16-31.*, 192.168.*, 127.*, localhost, or internal hostnames). If suspicious endpoints are found, investigate who configured them and when.

Detection guidance

Monitor HTTP/HTTPS traffic originating from the LibreChat server process to internal network ranges or cloud metadata endpoints (169.254.169.254). Check LibreChat application logs for HTTP requests initiated to unusual or private IP addresses. Audit the LibreChat settings or configuration backend for baseURL entries that do not match known external API endpoints (e.g., official OpenAI API domains). Implement Web Application Firewall rules that block baseURL parameters containing RFC 1918 addresses or localhost references at the input validation layer. Query network flow data for out-of-band connections from the application server to internal services that are not part of normal operation.

Why prioritize this

This vulnerability merits high priority despite requiring authentication. The CVSS score of 7.7 reflects high confidentiality impact; an attacker can access internal services and exfiltrate sensitive data (database credentials, API keys, internal documentation) exposed by those services. While direct availability or integrity impact is not scored, compromising internal systems often enables downstream attacks. The ease of exploitation (simple parameter change) combined with the potential to bypass network segmentation controls makes it a strong candidate for rapid patching. Organizations should prioritize this especially if they allow untrusted users to create or share LibreChat accounts, or if LibreChat runs alongside sensitive internal services.

Risk score, explained

CVSS 7.7 (HIGH) is justified by: Attack Vector: Network (the vulnerability is reachable remotely via HTTP/HTTPS), Access Complexity: Low (no special conditions required), Privileges Required: Low (authentication is required but any valid user can exploit it), User Interaction: None (no user action is needed once credentials are compromised), Scope: Changed (exploitation can impact confidentiality of systems beyond LibreChat itself), Confidentiality: High (internal service responses and data become accessible), Integrity: None (the attacker cannot modify responses), Availability: None (the attacker cannot directly cause denial of service). The scope change reflects the ability to reach systems outside the application's intended trust boundary.

Frequently asked questions