CVE-2026-31945
Received Received - Intake
Server-Side Request Forgery in LibreChat Allows Internal Access

Publication date: 2026-03-27

Last updated on: 2026-03-30

Assigner: GitHub, Inc.

Description
LibreChat is a ChatGPT clone with additional features. Versions 0.8.2-rc2 through 0.8.2 are vulnerable to a server-side request forgery (SSRF) attack when using agent actions or MCP. Although a previous SSRF vulnerability (https://github.com/danny-avila/LibreChat/security/advisories/GHSA-rgjq-4q58-m3q8) was reported and patched, the fix only introduced hostname validation. It does not verify whether DNS resolution results in a private IP address. As a result, an attacker can still bypass the protection and gain access to internal resources, such as an internal RAG API or cloud instance metadata endpoints. Version 0.8.3-rc1 contains a patch.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-27
Last Modified
2026-03-30
Generated
2026-05-07
AI Q&A
2026-03-27
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
librechat librechat 0.8.2
librechat librechat 0.8.2
librechat librechat 0.8.2
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-918 The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-31945 is a high-severity Server-Side Request Forgery (SSRF) vulnerability affecting LibreChat versions 0.8.2-rc2 through 0.8.2. The vulnerability occurs because the existing SSRF protections only validate hostnames but do not verify whether the DNS resolution results in private IP addresses.

Attackers can exploit this by using domains that resolve to private IPs, such as wildcard DNS services like nip.io or custom DNS servers controlled by the attacker. This allows them to bypass hostname validation and access internal resources, including internal RAG APIs or cloud instance metadata endpoints.

A proof of concept shows exploitation on AWS EC2 instances by specifying a domain like 169.254.169.254.nip.io, which resolves to the EC2 instance metadata endpoint. Attackers can use arbitrary HTTP methods to obtain metadata tokens and retrieve sensitive information such as the AMI ID.

The vulnerability arises because the patch only checked hostnames but not the resolved IP addresses, allowing attackers to perform SSRF attacks by resolving domains to private IPs and scanning private IP ranges.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability allows attackers to bypass hostname validation and access internal resources, including cloud instance metadata endpoints, potentially leading to unauthorized access to sensitive information.

Such unauthorized access and potential credential theft could lead to violations of data protection regulations like GDPR and HIPAA, which require strict controls over access to sensitive personal and health information.

Therefore, exploitation of this SSRF vulnerability could compromise confidentiality requirements mandated by these standards, impacting compliance.


How can this vulnerability impact me? :

This vulnerability can allow attackers to bypass protections and access internal resources that should not be exposed externally.

Specifically, attackers can access internal APIs, cloud instance metadata endpoints, and other sensitive internal services.

On cloud platforms like AWS, attackers can retrieve sensitive metadata such as AMI IDs and potentially steal credentials by exploiting the instance metadata service.

This can lead to severe security breaches including unauthorized access to confidential information and internal infrastructure.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for unusual outbound requests from LibreChat to internal or private IP addresses that should not normally be accessed. Since the SSRF attack exploits DNS names resolving to private IPs, detection involves identifying requests to suspicious domains that resolve to private IP ranges such as 169.254.x.x or 172.16.x.x.

Commands to detect such activity could include network traffic inspection tools or DNS resolution checks. For example, you can use the following commands to check DNS resolution and network connections:

  • Use dig or nslookup to resolve suspicious domains to IP addresses: dig example.nip.io or nslookup example.nip.io
  • Use netstat or ss to monitor outbound connections from the LibreChat server: netstat -tnp | grep librechat or ss -tnp | grep librechat
  • Use tcpdump or Wireshark to capture and analyze outbound HTTP requests to private IP ranges: tcpdump -i eth0 dst net 169.254.0.0/16 or tcpdump -i eth0 dst net 172.16.0.0/12

Additionally, reviewing LibreChat logs for agent actions or MCP requests that specify external domains resolving to private IPs can help identify exploitation attempts.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves upgrading LibreChat to version 0.8.3-rc1 or later, where the vulnerability has been patched.

The patch improves SSRF protection by validating the resolved IP addresses after DNS resolution to ensure they are not private IPs, preventing attackers from bypassing hostname validation.

If upgrading immediately is not possible, consider implementing network-level controls such as firewall rules to block outbound HTTP requests from LibreChat to private IP address ranges (e.g., 169.254.0.0/16, 172.16.0.0/12) to limit exploitation.

Also, monitor and restrict agent actions or MCP features that allow specifying arbitrary URLs to reduce the attack surface.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart