LibreChat is an enhanced ChatGPT clone that supports multiple AI providers

CVE-2026-31942 is an authenticated IDOR/mass-assignment bug in LibreChat’s PUT /api/keys endpoint. In affected builds, the route passes userId: req.user.id and then spreads ...req.body, so an attacker-supplied userId overrides the authenticated user and lets any logged-in user overwrite another user’s stored provider key data. The GitHub advisory lists affected versions as <= 0.7.6, with a fix in 0.8.3-rc1 published on 2026-06-02.

Vendor HIGH is technically defensible in a lab because this is cross-user integrity failure over the network with low privileges. In real enterprise deployments it lands lower: the attacker must already have an account, must know or obtain a victim userId, and only gets leverage where LibreChat is actually using per-user stored API keys; this is not pre-auth, not host compromise, and not a clean data-exfil primitive on its own.

Why this verdict

• Down from vendor HIGH: requires authenticated remote access, which implies the attacker already cleared your identity layer and is not exploiting the internet-facing edge cold.
• Further down: the attacker also needs a victim userId; the advisory shows overwrite logic, not a built-in enumeration primitive, so the exploit chain has a real dependency.
• Impact is narrower than raw CVSS suggests: this tampers with stored provider keys and can disrupt or potentially observe future provider traffic, but it is not server RCE, database dump, or tenant-admin takeover.
• Population is narrower: only deployments that let users store their own provider/API keys get the full impact. Environments using centrally managed server-side keys reduce the practical value of the bug.
• Still not low: this is cross-user authorization failure in a multi-user app, and once the prerequisites are met the overwrite itself is easy and reliable.

Why not higher?

This is not pre-auth and not broadly wormable. It does not provide direct code execution, direct read access to all chats, or immediate control of the LibreChat host; exploitation value depends on a second condition that many shops will not meet, namely active use of per-user stored provider keys.

Why not lower?

The authorization failure is real, cross-user, and easy to execute once prerequisites are satisfied. In shared internal AI portals, letting one ordinary user silently replace another user’s API key is a serious integrity break with plausible downstream confidentiality consequences.

1. Disable or avoid user-stored provider keys where possible — If your deployment can use centrally managed service credentials instead of user_provided keys, do that; it removes most of the exploit value because there is no per-user key record worth hijacking. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this is worth doing earlier if your tenant model is shared.
2. Audit and alert on PUT /api/keys — Log request metadata, actor, target record, provider name, and old/new key events so cross-user key churn becomes visible. There is no mitigation SLA for this severity, but deploy the telemetry on your normal change cadence so you are not blind while you wait for remediation.
3. Reduce low-privilege account sprawl — This vuln only exists after login, so tightening invites, dormant accounts, SSO groups, and MFA materially lowers exposure. Again, no mitigation SLA — go straight to the 365-day remediation window unless this is an externally accessible multi-user portal.
4. Review where user IDs are exposed — The exploit is much easier if userId values leak through logs, exports, browser responses, or admin tooling. Minimize that exposure and sanitize support artifacts to preserve the main friction point that keeps this bug from being a higher-priority fire.

Run this on the LibreChat host, inside the LibreChat container, or in CI against a checked-out source tree. Invoke it with python3 check_cve_2026_31942.py /app (Docker default example) or python3 check_cve_2026_31942.py /path/to/LibreChat; it only needs read access to the application files.

#!/usr/bin/env python3
# CVE-2026-31942 verification helper for LibreChat
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

import json
import os
import re
import sys
from pathlib import Path

VULN_ROUTE = Path('api/server/routes/keys.js')
PACKAGE_JSON = Path('package.json')


def parse_semver(v):
    # Supports forms like 0.7.6, v0.7.6, 0.8.3-rc1
    v = v.strip()
    if v.startswith('v'):
        v = v[1:]
    m = re.match(r'^(\d+)\.(\d+)\.(\d+)(?:-([A-Za-z]+)(\d+)?)?$', v)
    if not m:
        return None
    major, minor, patch, pre_label, pre_num = m.groups()
    major, minor, patch = int(major), int(minor), int(patch)
    if pre_label is None:
        pre_rank = 1  # stable > prerelease
        pre_label = ''
        pre_num = 0
    else:
        pre_rank = 0
        pre_num = int(pre_num) if pre_num else 0
    return (major, minor, patch, pre_rank, pre_label, pre_num)


def cmp_ver(a, b):
    return (a > b) - (a < b)


def read_version(root):
    pkg = root / PACKAGE_JSON
    if not pkg.exists():
        return None
    try:
        data = json.loads(pkg.read_text(encoding='utf-8'))
        return data.get('version')
    except Exception:
        return None


def inspect_route(root):
    route = root / VULN_ROUTE
    if not route.exists():
        return None
    try:
        text = route.read_text(encoding='utf-8', errors='ignore')
    except Exception:
        return None

    # Vulnerable pattern from advisory
    if 'await updateUserKey({ userId: req.user.id, ...req.body });' in text:
        return 'vulnerable'

    # Likely fixed pattern from advisory
    fixed_markers = [
        'const { name, value, expiresAt } = req.body;',
        'await updateUserKey({ userId: req.user.id, name, value, expiresAt });'
    ]
    if all(marker in text for marker in fixed_markers):
        return 'patched'

    # Heuristic: if req.body is spread into updateUserKey after userId, flag as vulnerable
    heuristic = re.search(r'updateUserKey\s*\(\s*\{[^}]*userId\s*:\s*req\.user\.id[^}]*\.\.\.req\.body[^}]*\}\s*\)', text, re.S)
    if heuristic:
        return 'vulnerable'

    return 'unknown'


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN - usage: python3 check_cve_2026_31942.py /path/to/LibreChat')
        sys.exit(2)

    root = Path(sys.argv[1]).resolve()
    if not root.exists() or not root.is_dir():
        print(f'UNKNOWN - path not found or not a directory: {root}')
        sys.exit(2)

    route_status = inspect_route(root)
    version = read_version(root)

    if route_status == 'vulnerable':
        print(f'VULNERABLE - code pattern matches CVE-2026-31942 in {root / VULN_ROUTE}')
        sys.exit(1)
    if route_status == 'patched':
        print(f'PATCHED - fixed code pattern found in {root / VULN_ROUTE}')
        sys.exit(0)

    if version:
        parsed = parse_semver(version)
        threshold = parse_semver('0.7.6')
        if parsed and threshold:
            if cmp_ver(parsed, threshold) <= 0:
                print(f'VULNERABLE - package.json version {version} is <= 0.7.6 and code pattern was inconclusive')
                sys.exit(1)
            else:
                print(f'PATCHED - package.json version {version} is > 0.7.6 and code pattern was inconclusive')
                sys.exit(0)

    print('UNKNOWN - could not confirm vulnerable route pattern or parse LibreChat version')
    sys.exit(2)


if __name__ == '__main__':
    main()

Sources

1. GitHub Security Advisory GHSA-5jcj-rh68-cgj7
2. LibreChat security advisory index
3. LibreChat docs: AI Endpoints (`user_provided` keys)
4. LibreChat docs: Custom Endpoints
5. LibreChat docs: Agents API and user-generated API keys
6. LibreChat quick start / deployment options
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS FAQ