CVE-2026-31943: LibreChat SSRF Vulnerability

CVE-2026-31943 Overview

CVE-2026-31943 is a Server-Side Request Forgery (SSRF) vulnerability in LibreChat, a popular open-source ChatGPT clone with enhanced features. The vulnerability exists in the isPrivateIP() function within packages/api/src/auth/domain.ts, which fails to properly detect IPv4-mapped IPv6 addresses in their hex-normalized form. This security flaw allows any authenticated user to bypass SSRF protection mechanisms and force the server to issue HTTP requests to internal network resources.

Critical Impact

Authenticated attackers can access cloud metadata services (e.g., AWS 169.254.169.254), loopback interfaces, and RFC1918 private network ranges, potentially leading to credential theft, internal service enumeration, and lateral movement within cloud environments.

Affected Products

• LibreChat versions prior to 0.8.3
• LibreChat 0.8.3-rc1
• LibreChat 0.8.3-rc2

Discovery Timeline

• 2026-03-27 - CVE-2026-31943 published to NVD
• 2026-03-31 - Last updated in NVD database

Technical Details for CVE-2026-31943

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery). The core issue lies in incomplete IP address validation within LibreChat's SSRF protection logic. The isPrivateIP() function is designed to block requests to internal network addresses, but it fails to account for IPv4-mapped IPv6 addresses when represented in their hex-normalized format.

IPv4-mapped IPv6 addresses (e.g., ::ffff:127.0.0.1 or ::ffff:169.254.169.254) can be expressed in multiple representations, including hexadecimal notation. When an attacker supplies these addresses in hex-normalized form, the validation function does not recognize them as internal addresses, allowing the request to pass through unfiltered.

The attack scope is particularly concerning because it allows access across security boundaries, enabling authenticated users to reach resources that should be strictly isolated from user-controlled requests.

Root Cause

The root cause is insufficient input validation in the IP address parsing logic. The isPrivateIP() function in packages/api/src/auth/domain.ts only checks for common IPv4 private address representations and standard IPv6 loopback addresses, but fails to normalize and validate IPv4-mapped IPv6 addresses before comparison. This creates a validation bypass where attackers can craft requests using alternative address representations that evade the blocklist checks.

Attack Vector

The attack vector is network-based and requires low-privilege authentication. An authenticated user can craft HTTP requests containing IPv4-mapped IPv6 addresses in hex-normalized form to target internal resources. The attack complexity is low, requiring no user interaction, and can be executed remotely against any vulnerable LibreChat instance.

Typical attack scenarios include:

• Accessing AWS/GCP/Azure metadata services to steal cloud credentials
• Probing internal network services via loopback (::ffff:7f00:0001)
• Scanning RFC1918 ranges for internal infrastructure discovery
• Accessing internal APIs and administrative interfaces not exposed to the internet

The vulnerability enables significant confidentiality impact through access to sensitive internal data and limited integrity impact through potential manipulation of internal services.

Detection Methods for CVE-2026-31943

Indicators of Compromise

• Outbound HTTP requests from LibreChat to cloud metadata endpoints (e.g., 169.254.169.254, 169.254.170.2)
• Requests containing IPv6 addresses in hex format targeting private ranges (e.g., ::ffff:7f00:0001)
• Unusual server-side requests to RFC1918 addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x)
• Access logs showing repeated requests to internal service endpoints from the LibreChat application

Detection Strategies

• Monitor network traffic for outbound connections from LibreChat servers to cloud metadata IP ranges
• Implement WAF rules to detect and block IPv4-mapped IPv6 addresses in hex-normalized format
• Review application logs for SSRF-related error messages or unusual URL patterns
• Deploy network segmentation monitoring to detect unauthorized internal service access

Monitoring Recommendations

• Configure cloud provider security tools to alert on metadata service access from application instances
• Enable detailed logging for the LibreChat API server, particularly for outbound HTTP requests
• Implement anomaly detection for unusual internal network traffic patterns originating from web application servers
• Set up alerts for any access to loopback or link-local addresses from application contexts

How to Mitigate CVE-2026-31943

Immediate Actions Required

• Upgrade LibreChat to version 0.8.3 or later immediately
• Review access logs for potential exploitation attempts targeting internal resources
• If upgrade is not immediately possible, restrict outbound network access from LibreChat servers using firewall rules
• Audit any cloud credentials that may have been exposed through metadata service access

Patch Information

The vulnerability is fixed in LibreChat version 0.8.3. Users should upgrade from any version prior to 0.8.3, including release candidates 0.8.3-rc1 and 0.8.3-rc2. The official security advisory is available at the GitHub Security Advisory for GHSA-w5r7-4f94-vp4c.

Workarounds

• Implement network-level SSRF protection by blocking outbound connections to private IP ranges and cloud metadata endpoints from LibreChat servers
• Deploy a web application firewall (WAF) with rules to detect and block IPv4-mapped IPv6 address patterns
• Use cloud provider metadata service hardening features (e.g., AWS IMDSv2 with hop limit restrictions)
• Apply network segmentation to limit LibreChat server access to only necessary external services

# Example iptables rules to block metadata service access
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 169.254.170.2 -j DROP

# Block RFC1918 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