CVE-2026-31944: 
NixOS vulnerability analysis and mitigation

CVE-2026-31944 is an OAuth callback session-binding vulnerability in LibreChat, an open-source ChatGPT-like platform, that allows an authenticated attacker to steal a victim's OAuth tokens and take over their linked MCP (Model Context Protocol) services. The flaw affects LibreChat versions 0.8.2 through 0.8.2-rc3 and was published on March 13, 2026. It carries a CVSS v3.1 base score of 7.6 (High) (GitHub Advisory, Red Hat CVE). The vulnerability is fixed in version 0.8.3-rc1 (GitHub Advisory).

The root cause is classified as CWE-306 (Missing Authentication for Critical Function): the MCP OAuth callback route (GET /:serverName/oauth/callback in api/server/routes/mcp.js, around line 108) lacks authentication middleware, unlike the /oauth/initiate endpoint which enforces requireJwtAuth (GitHub Advisory). The handler resolves user identity exclusively from the OAuth state parameter (used as a flowId to retrieve cached flow state), never reading req.user or any session/cookie to verify who is currently in the browser. As a result, MCPTokenStorage.storeTokens() always writes tokens to the flow initiator's account (flowState.userId), regardless of which user's browser completes the IdP redirect. This constitutes an OAuth session fixation / cross-user token binding flaw, enabling a social-engineering-based token theft attack (GitHub Advisory).

A successful attack results in the victim's OAuth access tokens for third-party services (e.g., Atlassian/Jira/Confluence, Microsoft Outlook) being stored on the attacker's LibreChat account, granting the attacker full read access to the victim's data on those services and limited write capability within the MCP integration's OAuth scopes (GitHub Advisory). The scope change is cross-boundary — the impact extends beyond LibreChat itself into external OAuth providers, potentially exposing emails, calendar data, Jira tickets, and other sensitive business data. There is no direct availability impact, and the attacker cannot modify the victim's LibreChat credentials or account data directly (GitHub Advisory).

A detailed 5-step proof-of-concept is publicly available in the GitHub Security Advisory, describing the exact attack flow with specific URLs and parameters (GitHub Advisory). The attacker must hold a valid LibreChat account (low privilege required) and must socially engineer the victim into clicking a crafted authorization URL; in some IdP configurations where prior consent exists, the victim may not need to interact beyond clicking the link. The EPSS score is 0.028% (low automated exploitation probability), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing at this time (Feedly). No threat actor attribution has been reported.

1. Attacker Setup: Log into a LibreChat instance (versions 0.8.2–0.8.2-rc3) with a valid user account.
2. Initiate OAuth Flow: Navigate to the MCP/Integrations section and begin an OAuth authorization flow for a target MCP server (e.g., Atlassian, Outlook).
3. Capture Authorization URL: When redirected to the identity provider (IdP) login/consent page, copy the full authorization URL from the browser address bar — this URL contains the state parameter tied to the attacker's flow session.
4. Deliver to Victim: Send the captured authorization URL to the victim via email, chat, or any social engineering channel (e.g., "Please approve this team integration").
5. Victim Completes Flow: The victim opens the URL, authenticates at the IdP if needed, and approves the OAuth consent screen. In some IdP configurations with prior consent, simply clicking the link is sufficient.
6. Token Theft: The IdP redirects to LibreChat's callback endpoint (/api/mcp/{serverName}/oauth/callback?code=...&state=...). Because the callback has no session validation, LibreChat exchanges the authorization code for tokens and stores them under the attacker's account (flowState.userId).
7. Access Victim's Services: The attacker now uses LibreChat's MCP integration to access the victim's Atlassian, Outlook, or other linked service data with the victim's OAuth tokens (GitHub Advisory).

• Network: Unexpected HTTP GET requests to /api/mcp/{serverName}/oauth/callback originating from IP addresses or user agents inconsistent with the account that initiated the OAuth flow; OAuth callback completions where the initiating session and completing session originate from different IPs or browsers.
• Logs: LibreChat application logs showing an OAuth callback (GET /:serverName/oauth/callback) completed by a browser with no authenticated session (req.user absent or mismatched) while tokens are stored for a different user ID; multiple OAuth flow completions for the same state/flowId from different source IPs.
• Application State: Unexpected MCP OAuth token entries in MCPTokenStorage for a user account where the token was obtained from an IP or device not associated with that user's normal activity; newly linked MCP service connections on a user account that the account owner did not initiate.
• User Reports: Victims reporting unexpected IdP consent prompts for LibreChat integrations they did not initiate, or receiving suspicious links purporting to be LibreChat OAuth authorization URLs (GitHub Advisory).

The primary remediation is to upgrade LibreChat to version 0.8.3-rc1 or later, which fixes the vulnerability (GitHub Advisory). The fix should add authentication middleware (e.g., requireJwtAuth) to the OAuth callback route and verify that the authenticated user matches flowState.userId before storing tokens. As an interim workaround for deployments that cannot immediately upgrade, administrators should consider disabling MCP OAuth integrations or restricting access to the MCP OAuth callback endpoint. Additionally, administrators should audit existing MCP token connections and instruct users to revoke any unexpected OAuth authorizations on linked services such as Atlassian and Outlook (GitHub Advisory).

The vulnerability was discussed on Mastodon/Infosec.exchange shortly after disclosure, and coverage appeared on security advisory aggregators including Yazoul, CCN-CERT (Spain's national cybersecurity center), and CyberHub Blog (Feedly). Red Hat tracked the CVE in their security database, indicating broader enterprise awareness (Red Hat CVE). No major vendor statements beyond the LibreChat project's own advisory have been identified, and community reaction has been moderate given the niche deployment base of LibreChat's MCP OAuth feature.