LibreChat CVE-2026-54024

Exploitation requires a valid authenticated user session (confirmed by CVSS PR:L). The POST /api/convos/import endpoint must be reachable by the attacker - standard for any network-accessible LibreChat deployment. The default configuration is vulnerable: CONVERSATION_IMPORT_MAX_FILE_SIZE_BYTES is commented out in .env.example, so no application-level cap is in place unless an administrator has explicitly configured it. Exploitation is blocked if: (1) the administrator has set CONVERSATION_IMPORT_MAX_FILE_SIZE_BYTES to a non-zero value, (2) a reverse proxy enforces upload size limits upstream, or (3) the instance restricts account creation and the attacker cannot obtain credentials. Deployments with open user self-registration face the highest risk, as the authentication gate provides minimal protection.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, score 6.5) is consistent with the described vulnerability. The network attack vector and low complexity are accurate - the endpoint is HTTP-accessible with no special preconditions. The PR:L rating is the primary risk-limiting factor: exploitation is gated on a valid authenticated session, which substantially narrows the attack surface compared to unauthenticated DoS vectors. However, LibreChat instances with open user registration effectively expose this to any user who can self-register. No EPSS probability was provided in the input data, so statistical exploitation likelihood cannot be quantified. There is no CISA KEV listing and no reported POC, suggesting no active exploitation at time of analysis. The patch-gap nature of this finding (one endpoint missed during a prior remediation) is notable - it reflects a class of incomplete fix issues that are often exploitable with minimal effort once the original CVE is public.

An attacker with a valid LibreChat account - potentially self-registered on a public instance - constructs a multipart HTTP POST request to /api/convos/import containing a payload of several gigabytes. Because the endpoint's multer instance has no fileSize limit and CONVERSATION_IMPORT_MAX_FILE_SIZE_BYTES is disabled by default, the server writes the full upload to disk and buffers it in memory. Repeating this in a loop or with multiple concurrent requests rapidly fills available disk and RAM, rendering the LibreChat service unavailable to all users.