Librechat EUVD-2026-16764

LibreChat versions prior to 0.8.3. Requires authenticated user account. Attacker exploits isPrivateIP() function bypass using IPv4-mapped IPv6 addresses in hex-normalized form to access internal resources (AWS metadata services, loopback, RFC1918 ranges) via SSRF.

The CVSS v3.1 score of 8.5 (High) reflects significant real-world risk driven by network-based attack vector (AV:N), low complexity (AC:L), and changed scope (S:C) with high confidentiality impact (C:H). The PR:L (low privileges required) indicator confirms this requires authenticated access, reducing the attack surface compared to unauthenticated SSRF. The changed scope is particularly concerning as it indicates the vulnerability can affect resources beyond the vulnerable component itself-specifically cloud metadata services that could expose IAM credentials, SSH keys, or API tokens. While no public exploit identified at time of analysis and no CISA KEV listing exists, SSRF vulnerabilities targeting cloud metadata services represent a well-understood attack pattern with numerous documented techniques. The technical simplicity of crafting hex-normalized IPv4-mapped IPv6 addresses makes this readily exploitable once an attacker has valid credentials. The automatable nature (UI:N) combined with potential access to high-value cloud credentials elevates this beyond typical web application SSRF to a critical cloud security concern for any LibreChat deployment in AWS, Azure, or GCP environments.

An authenticated attacker with low-level privileges logs into a cloud-hosted LibreChat instance and exploits a feature that accepts URLs (such as web scraping, document import, or API integration functionality). Instead of providing a legitimate external URL, the attacker submits a crafted request using a hex-normalized IPv4-mapped IPv6 address representation of 169.254.169.254 (AWS metadata service), such as http://[::ffff:0xA9FE:0xA9FE]/latest/meta-data/iam/security-credentials/. The flawed isPrivateIP() function fails to recognize this as an internal address, allowing the request to proceed. The server retrieves and returns IAM temporary credentials to the attacker, who then uses these credentials to access the organization's AWS resources, escalate privileges, or exfiltrate data from S3 buckets and databases associated with the compromised role.