LibreChat is an enhanced ChatGPT clone that supports multiple AI providers

LibreChat versions <= 0.8.3 let an authenticated user create an MCP server entry whose URL contains ${ENV_VAR} placeholders. During validation, LibreChat resolves those placeholders against the server process environment, then immediately performs a server-side connection test to the attacker-controlled URL. That turns a low-privileged MCP configuration action into outbound exfiltration of high-value secrets such as JWT_SECRET, CREDS_KEY, CREDS_IV, and potentially MONGO_URI.

The vendor's CRITICAL 9.6 score is technically defensible on *impact* because leaked JWT signing material and encryption keys can collapse the trust boundary for the entire instance. But for enterprise patch prioritization, the score runs hot: exploitation requires authenticated remote access to LibreChat first, and LibreChat is a self-hosted, comparatively narrow product with far smaller exposed population than mainstream edge software. Real-world severity is still serious, but it is *post-auth serious*, not *drop-everything pre-auth edge RCE* serious.

Why this verdict

• Downgrade for attacker position: the chain starts at *authenticated remote*, which implies either prior compromise, valid insider access, or intentionally broad user enrollment.
• Keep it high for blast radius: leaking JWT_SECRET, CREDS_KEY, and CREDS_IV can invalidate the security boundary of the whole LibreChat instance, not just one user account.
• Downgrade for reachable population: LibreChat is a self-hosted AI frontend with meaningful but limited enterprise exposure; this is not a mass-exposed appliance or ubiquitous browser/runtime bug.
• Downgrade for control friction: outbound callback to an attacker host is central to the exploit, so proxy allowlists, egress filtering, and container network policy can break the chain.
• No exploitation multiplier: no KEV listing and no primary-source evidence of active campaigns were found, so there is no reason to override into emergency-kev severity.

Why not higher?

This is not unauthenticated remote compromise. Requiring a valid LibreChat user session materially narrows who can exploit it and usually implies the attacker is already inside an identity boundary. The exploit also depends on successful outbound connectivity from the LibreChat server to attacker infrastructure, which many mature environments can restrict.

Why not lower?

Calling this medium would ignore what is actually being leaked. Once JWT_SECRET and encryption material leave the box, the attacker can plausibly forge sessions and unlock stored provider credentials, which is far beyond a minor data exposure. The follow-on blast radius is large enough that this still belongs in the high-priority queue.

1. Block arbitrary egress from LibreChat — Restrict the LibreChat container or host so it can only reach approved MCP destinations and required upstream services; deny generic outbound internet access. This directly breaks the exfiltration callback stage and should be deployed within 30 days if you cannot patch immediately.
2. Disable user-managed MCP server creation — Temporarily remove or gate the ability for ordinary users to create custom MCP servers until all instances are upgraded. This cuts off the attacker-controlled input path and should be enforced within 30 days on affected deployments.
3. Constrain LibreChat behind SSO/VPN — If any instance is internet-accessible, put it behind enterprise SSO, VPN, or both, and disable open self-registration where possible. That reduces the pool of attackers who can satisfy the PR:L prerequisite and should be done within 30 days for exposed systems.
4. Hunt for suspicious MCP URLs — Search app, proxy, and API logs for POST /api/mcp/servers plus URL values containing ${, attacker domains, or unusual query strings. Start this review now and complete the initial sweep within 30 days so you can decide whether key rotation is required.
5. Prepare secret rotation — Have a runbook ready to rotate JWT_SECRET, CREDS_KEY, CREDS_IV, and any provider credentials if you find evidence of abuse or cannot rule it out. The prep work belongs within 30 days, even if rotation is only triggered by compromise indicators.

Run this on the LibreChat host or inside the LibreChat container. Invoke it as bash check_cve_2026_32625.sh /path/to/LibreChat or bash check_cve_2026_32625.sh --container librechat. It needs local read access to the install path or permission to run docker inspect / docker exec.

#!/usr/bin/env bash
# check_cve_2026_32625.sh
# Detect likely exposure to CVE-2026-32625 in LibreChat.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

set -u

usage() {
  echo "Usage: $0 <librechat_path> | --container <docker_container_name>"
}

normalize_version() {
  local v="$1"
  v="${v#v}"
  echo "$v"
}

classify_version() {
  local raw="$1"
  local v
  v="$(normalize_version "$raw")"

  # Known vulnerable range from advisory: <= 0.8.3
  # Known fixed version: 0.8.4-rc1 and later.
  case "$v" in
    0.8.0*|0.8.1*|0.8.2*|0.8.3*)
      echo "VULNERABLE"
      return 1
      ;;
    0.8.4-rc1*|0.8.4-rc2*|0.8.4*|0.8.5*|0.8.6*|0.9*|1.*)
      echo "PATCHED"
      return 0
      ;;
    *)
      echo "UNKNOWN"
      return 2
      ;;
  esac
}

extract_version_from_path() {
  local base="$1"
  local f
  for f in \
    "$base/package.json" \
    "$base/client/package.json" \
    "$base/api/package.json" \
    "$base/node_modules/@librechat/api/package.json"; do
    if [ -f "$f" ]; then
      local ver
      ver=$(grep -E '"version"\s*:\s*"[^"]+"' "$f" | head -n1 | sed -E 's/.*"version"\s*:\s*"([^"]+)".*/\1/')
      if [ -n "$ver" ]; then
        echo "$ver"
        return 0
      fi
    fi
  done
  return 1
}

extract_version_from_container() {
  local c="$1"

  if ! command -v docker >/dev/null 2>&1; then
    return 1
  fi

  local image
  image=$(docker inspect --format '{{.Config.Image}}' "$c" 2>/dev/null) || return 1

  # Prefer explicit image tag if present.
  if echo "$image" | grep -q ':'; then
    local tag="${image##*:}"
    if [ -n "$tag" ] && [ "$tag" != "$image" ]; then
      echo "$tag"
      return 0
    fi
  fi

  # Fallback: inspect package.json inside the container.
  local ver
  ver=$(docker exec "$c" sh -lc '
    for f in /app/package.json /app/client/package.json /app/api/package.json /app/node_modules/@librechat/api/package.json; do
      if [ -f "$f" ]; then
        grep -E '"'"'version"'"'\s*:\s*"'"'[^"']+'"'"' "$f" | head -n1 | sed -E 's/.*"'"'version"'"'\s*:\s*"'"'([^"']+)"'"'.*/\1/' && exit 0
      fi
    done
    exit 1
  ' 2>/dev/null) || true

  if [ -n "$ver" ]; then
    echo "$ver"
    return 0
  fi

  return 1
}

if [ "$#" -lt 1 ]; then
  usage
  echo "UNKNOWN"
  exit 3
fi

version=""

if [ "$1" = "--container" ]; then
  if [ "$#" -ne 2 ]; then
    usage
    echo "UNKNOWN"
    exit 3
  fi
  version=$(extract_version_from_container "$2") || true
else
  if [ "$#" -ne 1 ]; then
    usage
    echo "UNKNOWN"
    exit 3
  fi
  version=$(extract_version_from_path "$1") || true
fi

if [ -z "$version" ]; then
  echo "UNKNOWN"
  exit 2
fi

classify_version "$version"
exit $?

Sources

1. GitHub Security Advisory GHSA-4pcc-j6m6-wcwx
2. LibreChat security advisories overview
3. Fix PR #12204: MCP Server URL Schema Validation
4. LibreChat releases
5. LibreChat container package metadata
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS API documentation