What is the CVSS score of CVE-2025-8849?

CVE-2025-8849 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.3%.

Which versions of LibreChat are affected by CVE-2025-8849?

LibreChat 0.7.9 memory API can be disrupted by an authenticated user who submits oversized key or value inputs, causing the Rust memory backend to fail and preventing new memories from being created…. A patch is available.

Is there a public PoC exploit available for CVE-2025-8849?

Yes, a public proof-of-concept exploit is available for CVE-2025-8849. Prioritise patching immediately. EPSS: 0.3%.

How to fix or mitigate CVE-2025-8849?

Patch available per vendor advisory; within 24 hours, inventory all LibreChat deployments, identify any instance running version 0.7.9 with the memory feature enabled and a valid memory agent, and apply the vendor patch per the vendor advisory; if immediate upgrade is not possible, disable the memory feature or block the POST /api/memories and PATCH /api/memories/:key routes for non-essential users while monitoring for memory creation failures. Within 7 days, upgrade every affected LibreChat 0.7.9 instance to the current vendor-patched release that includes the upstream 100KB payload limit and 1000-character key / 10000-character value validation, and confirm the checkMemoryCreate/checkMemoryUpdate middleware is enforced. Within 30 days, add regression tests for oversized key and value inputs, tune API gateway or WAF rules to reject payloads above 100KB, review logs for repeated authenticated memory API abuse, and document patch status and any exceptions for security management.

LibreChat CVE-2025-8849

HIGH

Uncontrolled Resource Consumption (CWE-400)

2025-10-31 security@huntr.dev

Denial Of Service Librechat

7.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

6.5 MEDIUM

Memory endpoints are behind auth middleware so PR:L not PR:N; network-reachable with trivial oversized input (AV:N/AC:L), availability-only impact (A:H), no confidentiality or integrity loss.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Oct 07, 2026 - 21:41 vuln.today

CVE Published

Oct 31, 2025 - 00:15 nvd

HIGH 7.5

DescriptionNVD

LibreChat version 0.7.9 is vulnerable to a Denial of Service (DoS) attack due to unbounded parameter values in the /api/memories endpoint. The key and value parameters accept arbitrarily large inputs without proper validation, leading to a null pointer error in the Rust-based backend when excessively large values are submitted. This results in the inability to create new memories, impacting the stability of the service.

AnalysisAI

Unbounded key and value parameters on the LibreChat 0.7.9 memory API (POST /api/memories and PATCH /api/memories/:key) allow an attacker to submit arbitrarily large inputs that cause a null pointer error in the Rust-based memory backend, leaving the service unable to create new memories and degrading overall stability. Exploitation is limited in practice to deployments where the memory feature is enabled with a valid memory agent and, because the routes sit behind the checkMemoryCreate/checkMemoryUpdate middleware, to a valid authenticated session - our assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (7.5), correcting NVD's PR:N rating. Publicly available exploit code exists, published through the huntr bounty program, but there is no confirmation of active exploitation and the issue is not in CISA KEV; it is neutralized once the 100kb payload limit and 1000-character key / 10000-character value checks from the upstream fix are applied.

Technical ContextAI

LibreChat is a Node.js/Express self-hosted chat application that persists user memories through a native (Rust-based) backend component. The memory creation and update routes in api/server/routes/memories.js accepted the key and value fields without length validation and without a route-scoped body size limit, so the default Express JSON parser would pass through arbitrarily large payloads to the memory service. The oversized data is not handled safely by the Rust component, producing a null pointer error that breaks memory creation. This is CWE-400 (Uncontrolled Resource Consumption): the root cause is the absence of bounds on attacker-controlled input plus a missing size constraint upstream of the parsing layer. The upstream fix adds express.json({ limit: '100kb' }) as route-level middleware on both the POST and PATCH memory routes, adds explicit guards that return HTTP 400 when a key exceeds 1000 characters or a value exceeds the configured charLimit, and centralizes memory configuration handling in @librechat/api (loadMemoryConfig/isMemoryEnabled) with charLimit defaulting to 10000 via the zod memorySchema. The only CPE recorded is cpe:2.3:a:librechat:librechat:0.7.9:-:*:*:*:*:*:*, indicating a version-specific defect rather than a design flaw affecting all releases.

RemediationAI

Apply the upstream fix commit edf33bedcbb08c33e59df76f06454ed7efd896f9 (see https://github.com/danny-avila/librechat/commit/edf33bedcbb08c33e59df76f06454ed7efd896f9) or upgrade to a LibreChat release that includes it; note that patch availability is confirmed at the commit level, so an independently verified tagged release should be checked before assuming the fix is shipped (upstream fix available via PR/commit; released patched version not independently confirmed). The fix enforces a 100kb JSON body limit on the memory routes, rejects keys longer than 1000 characters and values longer than the configured charLimit (default 10000) with HTTP 400, and defaults charLimit to 10000 through the zod memorySchema. If you cannot patch immediately, the most effective compensating control is to disable the memory feature outright (set memory.disabled to true or remove the valid memory agent configuration) - the trade-off is loss of persistent memory functionality for all users. Alternatively, front the application with a reverse proxy or ingress that enforces a client body size limit near 100kb and rejects oversized JSON on /api/memories - this is coarse, may need to be scoped carefully so it does not break other endpoints, and does not validate individual field lengths. Additionally, ensure the application is not exposed unauthenticated and restrict memory-creation permissions, since the affected routes are already gated by checkMemoryCreate/checkMemoryUpdate middleware and require a valid session in practice. Reporting and bounty details are available at https://huntr.com/bounties/e9d9404c-cd19-4226-a580-9cba14b7d7d6.