CVE-2026-31945: Librechat SSRF Vulnerability

CVE-2026-31945 Overview

CVE-2026-31945 is a Server-Side Request Forgery (SSRF) vulnerability affecting LibreChat, an open-source ChatGPT clone with additional features. The vulnerability exists in versions 0.8.2-rc2 through 0.8.2 when using agent actions or Model Context Protocol (MCP) features. Despite a previous SSRF fix that introduced hostname validation, the patch failed to verify whether DNS resolution results in a private IP address, allowing attackers to bypass protections through DNS rebinding techniques.

Critical Impact

Attackers can exploit this vulnerability to access internal resources including internal RAG APIs and cloud instance metadata endpoints, potentially exposing sensitive credentials and configuration data.

Affected Products

• LibreChat version 0.8.2
• LibreChat version 0.8.2-rc2
• LibreChat version 0.8.2-rc3

Discovery Timeline

• 2026-03-27 - CVE-2026-31945 published to NVD
• 2026-03-30 - Last updated in NVD database

Technical Details for CVE-2026-31945

Vulnerability Analysis

This SSRF vulnerability arises from an incomplete fix for a previously reported security issue (GHSA-rgjq-4q58-m3q8). The original patch implemented hostname validation to prevent SSRF attacks, but the mitigation was insufficient because it only validated the hostname string without verifying the actual IP address returned during DNS resolution.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery), which occurs when a web application fetches a remote resource without sufficiently validating the user-supplied URL. In this case, the application's agent actions and MCP functionality make outbound requests that can be manipulated by an attacker.

Root Cause

The root cause stems from a Time-of-Check to Time-of-Use (TOCTOU) race condition in the URL validation logic. The hostname is validated at check time, but DNS resolution occurs later at use time. An attacker can leverage DNS rebinding techniques where the initial DNS response returns a valid external IP address (passing validation), but subsequent resolutions return internal/private IP addresses.

The validation logic checks if the hostname matches known internal patterns (like localhost, 127.0.0.1, or reserved domain names) but fails to verify that the resolved IP address is not within private IP ranges (RFC 1918 addresses like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or other reserved address spaces.

Attack Vector

The attack is network-based and requires low-privileged access to the LibreChat application. An authenticated user can craft malicious URLs targeting agent actions or MCP endpoints. The attacker sets up a DNS server that initially resolves their controlled domain to a public IP address, then quickly switches to resolve to an internal IP address.

The exploitation flow involves the attacker submitting a URL with their controlled domain to LibreChat's agent action feature. LibreChat validates the hostname, which appears legitimate, and the attacker's DNS server initially returns a public IP. When LibreChat makes the actual request, the DNS response returns an internal IP address such as 169.254.169.254 (cloud metadata endpoint) or internal service addresses, granting the attacker access to internal resources.

This technique is particularly dangerous in cloud environments where metadata endpoints at 169.254.169.254 contain sensitive information including IAM credentials, instance configuration, and API tokens.

Detection Methods for CVE-2026-31945

Indicators of Compromise

• Unusual outbound requests from LibreChat services to internal IP ranges or metadata endpoints
• DNS queries from the LibreChat server to suspicious or recently registered domains
• Access attempts to cloud metadata services (169.254.169.254) from application containers
• Network connections to RFC 1918 private address ranges originating from LibreChat

Detection Strategies

• Monitor network traffic from LibreChat instances for connections to private IP ranges that should not be accessible
• Implement DNS logging and alert on rapid DNS changes (TTL abuse) for domains accessed by the application
• Deploy web application firewalls (WAF) rules to detect SSRF patterns in agent action or MCP requests
• Enable cloud provider metadata endpoint protection and audit logs

Monitoring Recommendations

• Configure network segmentation monitoring to detect lateral movement attempts via SSRF
• Implement egress filtering alerts for LibreChat application servers attempting to access internal services
• Review application logs for agent action requests containing suspicious URLs or patterns
• Monitor for increased DNS resolution failures or TTL anomalies associated with DNS rebinding attempts

How to Mitigate CVE-2026-31945

Immediate Actions Required

• Upgrade LibreChat to version 0.8.3-rc1 or later, which contains the security patch
• If immediate upgrade is not possible, disable agent actions and MCP features until patching is complete
• Implement network-level controls to restrict outbound connections from LibreChat servers
• Block access to cloud metadata endpoints from application containers using firewall rules

Patch Information

The vulnerability has been addressed in LibreChat version 0.8.3-rc1. The patch implements proper IP address validation after DNS resolution to ensure the resolved address is not within private or reserved IP ranges. Organizations should upgrade to this version or later to remediate the vulnerability.

For detailed patch information and security advisory, refer to the GitHub Security Advisory GHSA-f92m-jpv7-55p2.

Workarounds

• Deploy network-level SSRF protections using a proxy that validates resolved IP addresses before allowing requests
• Configure firewall rules to prevent the LibreChat application from accessing internal networks and metadata endpoints
• Implement DNS pinning or resolution caching to prevent DNS rebinding attacks at the infrastructure level

# Example: Block metadata endpoint access using iptables
# Run on LibreChat server to prevent metadata endpoint access
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Block common private IP ranges from application server
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP