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

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

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

LibreChat 0.7.9 contains a high-severity vulnerability that allows an authenticated user to disable two-factor authentication on their own account without providing a valid TOTP token or backup code.. A patch is available.

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

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

How to fix or mitigate CVE-2025-8850?

Patch available per vendor advisory; within 24 hours, identify all LibreChat 0.7.9 deployments, apply the available upstream fix commit or vendor patch, and if immediate patching is not possible, restrict or monitor access to the POST /api/auth/2fa/disable endpoint and alert on 2FA-disable events. Within 7 days, upgrade every LibreChat instance beyond 0.7.9 to a version containing the fix, audit local-provider accounts for unexpected 2FA disablement, and re-enable 2FA where it was turned off without a valid token. Within 30 days, review authentication logs for suspicious 2FA changes, confirm that no affected accounts remain on 0.7.9, and update configuration baselines to require re-authentication or a valid second factor for any security-setting change.

LibreChat CVE-2025-8850

HIGH

Expected Behavior Violation (CWE-440)

2025-10-30 security@huntr.dev

Authentication Bypass Librechat

8.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.8 HIGH

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

vuln.today AI

4.3 MEDIUM

Authenticated user (PR:L) acting only on their own account over the network; no data disclosure (C:N) and no availability loss (A:N), just a minor self-inflicted integrity/security downgrade (I:L).

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

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

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Oct 07, 2026 - 21:45 vuln.today

CVE Published

Oct 30, 2025 - 20:15 nvd

HIGH 8.8

DescriptionNVD

In danny-avila/librechat version 0.7.9, there is an insecure API design issue in the 2-Factor Authentication (2FA) flow. The system allows users to disable 2FA without requiring a valid OTP or backup code, bypassing the intended verification process. This vulnerability occurs because the backend does not properly validate the OTP or backup code when the API endpoint '/api/auth/2fa/disable' is directly accessed. This flaw can be exploited by authenticated users to weaken the security of their own accounts, although it does not lead to full account compromise.

AnalysisAI

LibreChat 0.7.9 lets an authenticated user turn off two-factor authentication on their own account without supplying a valid TOTP token or backup code, because the POST /api/auth/2fa/disable handler skips the second-factor verification that the rest of the 2FA flow enforces. The scope is narrow: the endpoint only affects the caller's own account, requires an existing authenticated session on a local-provider account that already had 2FA enabled (PR:L per the vector), and does not enable account takeover - our authoritative assessment therefore scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, far below the published 8.8 vector, which overstates C/I/A. Publicly available exploit code exists (the Huntr bounty write-up), an upstream fix commit is available, and there is no indication of confirmed active exploitation (no CISA KEV listing).

Technical ContextAI

LibreChat is a Node.js/Express self-hosted chat application that stores a per-user TOTP secret (totpSecret) and a set of backup codes and exposes 2FA management through the API routes under /api/auth/2fa/. The front end, via packages/data-provider, called disableTwoFactor() with no request body, and the pre-patch TwoFactorController on the server performed no verification before clearing totpSecret, backupCodes and twoFactorEnabled. The root-cause class is CWE-440 (Expected Behavior Violation): the handler simply did not implement the verification behavior the endpoint contract implies, so a direct POST to /api/auth/2fa/disable with an authenticated session silently removed the second factor. The reference commit (7e4c8a5d0d2dbe5bf8fd272ff6acafb27d24744f) demonstrates the intended design: it destructures { token, backupCode } from req.body, returns HTTP 400 when neither is supplied, calls verifyTOTP(secret, token) or verifyBackupCode({ user, backupCode }) when twoFactorEnabled is true, and returns HTTP 401 on a failed check - matching the pattern already used by the confirm-2FA path. The corresponding client-side changes pass a TDisable2FARequest payload through the data service. CPE data confirms only the open-source LibreChat codebase at version 0.7.9 is affected; no downstream vendor builds are identified in the supplied intelligence.

RemediationAI

Apply the upstream fix from https://github.com/danny-avila/librechat/commit/7e4c8a5d0d2dbe5bf8fd272ff6acafb27d24744f, or upgrade to the first LibreChat release that contains it (the supplied data identifies the commit but not a tagged version, so verify the release notes before assuming a version number). After patching, the endpoint returns HTTP 400 when neither token nor backupCode is supplied and HTTP 401 when verification fails, closing the bypass. Also re-enable 2FA on any affected account and review authentication logs for POST requests to /api/auth/2fa/disable that cleared twoFactorEnabled, since an attacker who already holds a session has effectively weakened a control intended to protect that session. If the patch cannot be applied immediately, compensating controls for self-hosted deployments include blocking or rate-limiting POST /api/auth/2fa/disable at the reverse proxy and requiring an out-of-band re-authentication before re-enabling it - the trade-off is that legitimate users then cannot self-service disable 2FA and will need administrator assistance, and any proxy rule must be kept in sync as the route evolves. A second option is to move affected users to an external identity provider (provider other than 'local'), which removes them from this code path entirely at the cost of re-provisioning accounts. Because the flaw only affects the caller's own account and does not permit account takeover, do not treat it as an emergency; prioritize it as a hardening and audit item.