CVE-2024-11171: Librechat DoS Vulnerability

CVE-2024-11171 Overview

CVE-2024-11171 is an improper input validation vulnerability in danny-avila/librechat version git 0c2a583. The application uses the multer middleware to handle multipart file uploads. Because multer defaults to in-memory storage without a file size limit, attackers can submit arbitrarily large files that exhaust server memory. This out-of-memory condition crashes the process and denies service to legitimate users. The flaw is unauthenticated, network-accessible, and requires no user interaction. LibreChat resolved the issue in version 0.7.6 by refactoring avatar upload handling to read files from disk and enforce validation via a filterFile function.

Critical Impact
An unauthenticated remote attacker can trigger a complete denial of service by uploading oversized files that exhaust server memory.

Affected Products

LibreChat prior to version 0.7.6
LibreChat git commit 0c2a583
Deployments using default multer in-memory storage configuration

Discovery Timeline

2025-03-20 - CVE-2024-11171 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-11171

Vulnerability Analysis

LibreChat's avatar upload endpoint accepts multipart form data through the multer Express middleware. The route instantiated multer() with no options, which selects the default in-memory storage engine and applies no file size limit. Every uploaded byte is buffered into the Node.js process heap before request handlers run.

An attacker can POST a single request containing a multi-gigabyte payload to the avatar upload endpoint. The Node.js process allocates memory proportional to the payload until the V8 heap limit is reached, at which point the process crashes with an out-of-memory error. This behavior maps to [CWE-770] Allocation of Resources Without Limits or Throttling.

Root Cause

The root cause is the unconfigured multer instance in api/server/routes/files/avatar.js. Instantiating const upload = multer() without a limits option or a disk-based storage engine causes every uploaded file to be buffered entirely in RAM. No pre-upload authentication check, size validation, or MIME filtering was applied before memory allocation occurred.

Attack Vector

Exploitation requires only network reachability to the LibreChat instance. An unauthenticated attacker sends a crafted multipart/form-data POST request to the avatar upload route with an oversized input field. Because the endpoint does not require prior authentication for the vulnerable code path and enforces no size limit, a single request is sufficient to exhaust process memory.

javascript

// Patch: api/server/routes/files/avatar.js
-const multer = require('multer');
+const fs = require('fs').promises;
 const express = require('express');
 const { getStrategyFunctions } = require('~/server/services/Files/strategies');
 const { resizeAvatar } = require('~/server/services/Files/images/avatar');
+const { filterFile } = require('~/server/services/Files/process');
 const { logger } = require('~/config');

-const upload = multer();
 const router = express.Router();

-router.post('/', upload.single('input'), async (req, res) => {
+router.post('/', async (req, res) => {
   try {
+    filterFile({ req, file: req.file, image: true, isAvatar: true });
     const userId = req.user.id;
     const { manual } = req.body;
-    const input = req.file.buffer;
+    const input = await fs.readFile(req.file.path);

     if (!userId) {
       throw new Error('User ID is undefined');
// Source: https://github.com/danny-avila/librechat/commit/bb58a2d0662ef86dc75a9d2f6560125c018e3836

The fix removes the in-memory multer instance, reads uploaded content from disk via fs.readFile, and routes the file through filterFile to validate size and type before processing.

Detection Methods for CVE-2024-11171

Indicators of Compromise

Node.js process crashes with FATAL ERROR: JavaScript heap out of memory or ENOMEM messages in LibreChat container logs
Repeated large POST requests to /api/files/avatar or /api/user/avatar endpoints with Content-Length values in the hundreds of megabytes or larger
Sudden spikes in resident set size (RSS) for the LibreChat Node.js process immediately preceding a restart

Detection Strategies

Inspect HTTP access logs for multipart/form-data uploads to avatar endpoints with abnormally large Content-Length headers
Correlate container or process restart events with preceding upload requests from the same source IP
Alert on repeated 5xx responses or connection resets from avatar upload routes

Monitoring Recommendations

Track memory utilization and OOM-kill events on hosts running LibreChat
Rate-limit and log unauthenticated requests to file upload endpoints at the reverse proxy layer
Monitor for the vulnerable LibreChat versions in software inventories and container image scans

How to Mitigate CVE-2024-11171

Immediate Actions Required

Upgrade LibreChat to version 0.7.6 or later, which contains the patch in commit bb58a2d
Place LibreChat behind a reverse proxy (nginx, Envoy, or a WAF) that enforces a maximum request body size
Restrict network access to the LibreChat instance until patching is complete

Patch Information

The fix is included in LibreChat 0.7.6 via commit bb58a2d. The patch removes default in-memory multer storage, reads files from disk with fs.readFile, and enforces validation via filterFile with an isAvatar parameter. Additional context is available in the Huntr Security Bounty report.

Workarounds

Configure an upstream reverse proxy to reject requests exceeding a sane upload ceiling (for example, client_max_body_size 10m; in nginx)
Require authentication on all upload endpoints via network-level controls if code changes are not possible
If forking the code, configure multer with explicit limits.fileSize and disk storage rather than the in-memory default

bash

# nginx reverse proxy hardening for LibreChat
server {
    listen 443 ssl;
    server_name librechat.example.com;

    # Reject oversized uploads before they reach Node.js
    client_max_body_size 10m;
    client_body_buffer_size 128k;
    client_body_timeout 10s;

    location /api/ {
        limit_req zone=uploads burst=5 nodelay;
        proxy_pass http://librechat_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}