What is the CVSS score of CVE-2026-31942?

CVE-2026-31942 has a CVSS 3.1 base score of 7.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L. EPSS exploitation probability: 0.0%.

Which versions of LibreChat are affected by CVE-2026-31942?

LibreChat versions up to 0.7.6 contain an authentication bypass flaw allowing any logged-in user to steal API credentials (OpenAI, Anthropic, Azure) belonging to other users, enabling unauthorized…

How to fix or mitigate CVE-2026-31942?

Within 24 hours: Identify all LibreChat deployments and their versions; if running 0.7.6 or earlier, immediately restrict API key management permissions to administrators only or disable the feature entirely. Within 7 days: Monitor vendor advisory for stable 0.8.3 release (currently available as 0.8.3-rc1 only); conduct testing in staging environment. Within 30 days: Deploy LibreChat 0.8.3 stable or later to all production systems; audit API key access logs for unauthorized modifications; rotate any potentially exposed API keys in OpenAI, Anthropic, and Azure accounts.

LibreChat CVE-2026-31942

HIGH

Missing Authorization (CWE-862)

2026-06-02 GitHub_M

Authentication Bypass Microsoft Librechat Danny Avila

7.1

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

7.1 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L

Primary rating from Vendor (GitHub_M) · only source for this CVE.

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

Low

Lifecycle Timeline

Analysis Generated

Jun 02, 2026 - 23:20 vuln.today

CVE Published

Jun 02, 2026 - 22:22 nvd

HIGH 7.1

DescriptionCVE.org

LibreChat is an enhanced ChatGPT clone that supports multiple AI providers. In versions up to and including 0.7.6, an Insecure Direct Object Reference (IDOR) vulnerability exists in the API keys management endpoint (PUT /api/keys). Due to the use of the JavaScript object spread operator after setting the authenticated user's ID, any authenticated user can inject a userId parameter in the request body to overwrite any other user's API keys (e.g., OpenAI, Anthropic, Azure). This allows an attacker to replace a victim's API key configuration, potentially routing the victim's conversations through attacker-controlled keys or denying service by providing invalid keys. This is patched in version 0.8.3-rc1.

AnalysisAI

Cross-user API key overwrite in LibreChat versions up to and including 0.7.6 allows any authenticated user to replace another user's stored provider API keys (OpenAI, Anthropic, Azure) by injecting a userId parameter into PUT /api/keys requests. The flaw stems from an Insecure Direct Object Reference where the JavaScript spread operator overrides the server-set authenticated user ID, enabling conversation hijacking or denial of service. No public exploit identified at time of analysis, and the issue is fixed in 0.8.3-rc1.

Technical ContextAI

LibreChat (cpe:2.3:a:danny-avila:librechat) is an open-source, self-hosted multi-provider chat interface that brokers requests to upstream LLM APIs using per-user stored credentials. The root cause is CWE-862 (Missing Authorization): the PUT /api/keys handler constructs its update document by spreading the request body after assigning req.user.id, so a client-supplied userId in the body shadows the trusted server value and the database write targets an arbitrary account. This is a classic order-of-assignment IDOR exacerbated by trusting client JSON in a privileged write path.

RemediationAI

Upgrade to LibreChat 0.8.3-rc1 or later, which is the vendor-released patched version per advisory GHSA-5jcj-rh68-cgj7 (https://github.com/danny-avila/LibreChat/security/advisories/GHSA-5jcj-rh68-cgj7). If immediate upgrade is not possible, disable open user registration so only trusted users can reach the authenticated endpoint, place an authenticating reverse proxy or WAF rule in front of PUT /api/keys to strip or reject any userId field in the request body, and rotate all stored provider API keys (OpenAI, Anthropic, Azure) after patching since prior overwrites may be undetected; the trade-off of WAF body-rewriting is potential breakage of legitimate future schema changes, and forcing key rotation will require users to re-enter credentials.