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

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

LibreChat CVE-2026-44653

MEDIUM

Insertion of Sensitive Information Into Sent Data (CWE-201)

2026-06-02 security-advisories@github.com

Information Disclosure Librechat

6.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.5 MEDIUM

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

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 02, 2026 - 23:33 vuln.today

DescriptionGitHub Advisory

LibreChat is an enhanced ChatGPT clone that supports multiple AI providers. In versions up to and including 0.8.3, users with only VIEW access to an MCP server can retrieve the server's decrypted admin-managed secrets through GET /api/mcp/servers and GET /api/mcp/servers/:serverName. The returned config includes plaintext values for apiKey.key and oauth.client_secret. This allows viewers of a shared MCP server to exfiltrate the underlying provider credentials. Version 0.8..4 contains a patch. Other remediations include: never returning decrypted admin-managed secrets to non-owners; redacting apiKey.key and oauth.client_secret from all API responses consider returning only boolean presence indicators for secrets, similar to the auth-values route pattern; and, if owners need to edit configs without re-entering secrets, preserving secrets server-side and returning placeholders instead of plaintext.

AnalysisAI

LibreChat's MCP server configuration API leaks decrypted admin-managed credentials - including plaintext API keys and OAuth client secrets - to any authenticated user holding only VIEW-level access to a shared MCP server. All deployments running versions up to and including 0.8.3 are affected, with the flaw accessible via standard GET requests to /api/mcp/servers and /api/mcp/servers/:serverName. No public exploit or active exploitation has been identified at time of analysis, but the low-complexity, low-privilege network vector makes credential exfiltration straightforward in any multi-user LibreChat environment.

Technical ContextAI

LibreChat implements a Model Context Protocol (MCP) abstraction layer enabling administrators to configure shared AI provider integrations with secrets such as API keys and OAuth client credentials stored server-side in encrypted form. CWE-201 (Insertion of Sensitive Information Into Sent Data) identifies the root cause: the API serialization layer returns the fully decrypted configuration object - including apiKey.key and oauth.client_secret fields - to the HTTP response without any secrets-scrubbing or redaction step. The CVSS vector AV:N/AC:L/PR:L/UI:N confirms the endpoints are network-accessible and require only the low-privilege VIEW permission, which is explicitly the access level designed for read-only consumers of shared MCP servers. The advisory notes that a correct pattern - returning boolean presence indicators rather than plaintext values - already exists in the auth-values route of the same codebase, making this a localized failure to apply a known internal standard.

RemediationAI

Upgrade LibreChat to version 0.8.4, which contains the official patch per GitHub Security Advisory GHSA-6vqg-rgpm-qvf9 (https://github.com/danny-avila/LibreChat/security/advisories/GHSA-6vqg-rgpm-qvf9). If immediate upgrade is not feasible, restrict VIEW access to MCP servers to fully trusted users only - this limits collaboration functionality but removes unauthorized viewers from the exploitable population. The advisory additionally recommends the following architectural controls as defense-in-depth: redacting apiKey.key and oauth.client_secret from all API responses and returning only boolean presence indicators (e.g., hasApiKey: true), consistent with the existing auth-values route pattern already in the codebase; and preserving secrets server-side while returning opaque placeholders to owners to avoid requiring secret re-entry during config edits. Regardless of upgrade status, all API keys and OAuth client secrets that were accessible to VIEW-permission users should be rotated immediately on affected provider platforms, as any exposure window since 0.8.3 deployment must be treated as a potential compromise.