CVE-2026-44653: LibreChat Information Disclosure Flaw

CVE-2026-44653 Overview

LibreChat is an open-source ChatGPT clone supporting multiple AI providers and Model Context Protocol (MCP) servers. CVE-2026-44653 is an information disclosure vulnerability [CWE-201] affecting LibreChat versions up to and including 0.8.3. Users granted only VIEW access to a Model Context Protocol (MCP) server can retrieve decrypted admin-managed secrets through the GET /api/mcp/servers and GET /api/mcp/servers/:serverName endpoints. The returned configuration includes plaintext values for apiKey.key and oauth.client_secret, enabling viewers to exfiltrate underlying provider credentials.

Critical Impact

Authenticated low-privilege users can harvest plaintext API keys and OAuth client secrets from shared MCP server configurations, leading to downstream compromise of connected AI providers and services.

Affected Products

• LibreChat versions 0.8.3 and earlier
• Deployments using shared MCP server configurations with VIEW-level role assignments
• Environments storing admin-managed API keys or OAuth client secrets in MCP server configs

Discovery Timeline

• 2026-06-02 - CVE-2026-44653 published to NVD
• 2026-06-03 - Last updated in NVD database

Technical Details for CVE-2026-44653

Vulnerability Analysis

The flaw resides in the MCP server configuration retrieval endpoints. LibreChat's authorization model distinguishes between owners and users with VIEW access on shared MCP servers. However, the API handlers serving GET /api/mcp/servers and GET /api/mcp/servers/:serverName decrypt admin-managed secrets server-side and return them in full to any caller authorized to read the configuration.

Viewers receive plaintext values for apiKey.key and oauth.client_secret in the JSON response. These fields are intended to remain confidential to the configuration owner. The decrypted payload allows a viewer to authenticate directly against the upstream provider using credentials owned by the admin, bypassing LibreChat as an intermediary.

Root Cause

The root cause is a missing authorization check on sensitive fields combined with unconditional decryption during serialization. The response builder does not differentiate between owners and viewers when assembling the config object, and it does not redact or substitute placeholders for secrets. This pattern is classified under [CWE-201]: Insertion of Sensitive Information Into Sent Data.

Attack Vector

Exploitation requires an authenticated account with VIEW access to a shared MCP server. The attacker issues an authenticated HTTP GET request to /api/mcp/servers or /api/mcp/servers/:serverName. The server responds with the full configuration, including decrypted apiKey.key and oauth.client_secret values. The attacker extracts the credentials and reuses them against the third-party AI provider or OAuth issuer.

No special tooling is required. A standard browser session, curl, or any HTTP client suffices once VIEW access has been granted.

Detection Methods for CVE-2026-44653

Indicators of Compromise

• Unexpected GET requests to /api/mcp/servers or /api/mcp/servers/:serverName from accounts that hold only VIEW permissions.
• Outbound API calls to provider endpoints (OpenAI, Anthropic, OAuth issuers) originating from hosts or IPs not associated with the LibreChat deployment.
• Provider-side anomalies such as unusual request volumes, new source IPs, or token use outside business hours tied to admin-managed keys.

Detection Strategies

• Enable verbose access logging on the LibreChat API and alert on VIEW-role users querying MCP server detail endpoints.
• Correlate LibreChat audit logs with provider-side usage logs to identify credentials used outside the LibreChat process.
• Rotate admin-managed secrets and monitor for continued use of the prior key, which indicates prior exfiltration.

Monitoring Recommendations

• Forward LibreChat application logs and reverse-proxy access logs to a centralized analytics platform for retention and search.
• Establish baselines for which user roles legitimately access MCP configuration endpoints and alert on deviations.
• Track issuance and rotation of admin-managed apiKey.key and oauth.client_secret values in a secrets inventory.

How to Mitigate CVE-2026-44653

Immediate Actions Required

• Upgrade LibreChat to version 0.8.4 or later, which contains the patch for this vulnerability.
• Rotate every apiKey.key and oauth.client_secret stored in MCP server configurations that have been shared with VIEW-role users.
• Audit the list of users granted VIEW access to MCP servers and revoke access that is no longer required.
• Review provider-side usage logs for the impacted credentials and revoke any tokens issued during the exposure window.

Patch Information

LibreChat version 0.8.4 resolves the issue. The maintainers recommend never returning decrypted admin-managed secrets to non-owners, redacting apiKey.key and oauth.client_secret from all API responses, and returning boolean presence indicators similar to the existing auth-values route pattern. When owners need to edit configs without re-entering secrets, the server should preserve secrets internally and return placeholders instead of plaintext. Details are available in the LibreChat GitHub Security Advisory GHSA-6vqg-rgpm-qvf9.

Workarounds

• Restrict MCP server sharing so that only trusted owners can view configurations until the patch is applied.
• Move sensitive provider credentials out of admin-managed MCP configs and into per-user authentication where viewers must supply their own keys.
• Place the LibreChat API behind a reverse proxy that strips apiKey.key and oauth.client_secret fields from responses on the /api/mcp/servers routes.

# Example: upgrade LibreChat to the patched release
git fetch --tags
git checkout v0.8.4
npm ci
npm run build
# Restart the LibreChat service after upgrade
systemctl restart librechat