CVE-2025-41258
Received Received - Intake
JWT Secret Reuse in LibreChat 0.8.1-rc2 Enables Authentication Bypass

Publication date: 2026-03-18

Last updated on: 2026-03-24

Assigner: sba-research

Description
LibreChat version 0.8.1-rc2 uses the same JWT secret for the user session mechanism and RAG API which compromises the service-level authentication of the RAG API.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-18
Last Modified
2026-03-24
Generated
2026-05-07
AI Q&A
2026-03-18
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
librechat librechat 0.8.1
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-284 The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

The vulnerability in LibreChat version 0.8.1-rc2 involves the use of the same JSON Web Token (JWT) secret for both user session management and the Retrieval-Augmented Generation (RAG) API service-level authentication.

Because the RAG API shares the JWT secret with the user sessions and does not validate audience claims or implement user-level access restrictions, an authenticated user can reuse their session JWT token to authenticate directly against the RAG API.

This design flaw allows attackers with valid LibreChat credentials to bypass proper authentication controls on the RAG API, potentially accessing, modifying, or deleting documents managed by the RAG API.


How can this vulnerability impact me? :

This vulnerability can have serious impacts including unauthorized access to sensitive data and manipulation of documents managed by the RAG API.

  • An attacker with valid LibreChat credentials can use their JWT token to access all RAG API endpoints.
  • They can read, replace, delete, or upload documents within the RAG API.
  • Since the RAG API typically resides within an internal network, exploitation requires internal network access or chaining with another vulnerability.

The vulnerability has a high severity score (CVSS 8.0) indicating high impact on confidentiality, integrity, and availability.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by testing whether a valid LibreChat user JWT token can be used to authenticate against the RAG API endpoints. Since unauthenticated requests to the RAG API return HTTP 401, but authenticated requests using the LibreChat JWT token return HTTP 200 with sensitive data, this behavior indicates the vulnerability.'}, {'type': 'paragraph', 'content': 'To detect this on your system, you can attempt to access the RAG API endpoints using a JWT token obtained from a logged-in LibreChat user session and observe the HTTP response codes.'}, {'type': 'paragraph', 'content': 'Example commands using curl might include:'}, {'type': 'list_item', 'content': '1. Obtain a valid JWT token from a logged-in LibreChat user session.'}, {'type': 'list_item', 'content': '2. Test unauthenticated access to a RAG API endpoint: curl -i http://<RAG_API_ENDPOINT> - expect HTTP 401 Unauthorized.'}, {'type': 'list_item', 'content': '3. Test authenticated access using the JWT token: curl -i -H "Authorization: Bearer <JWT_TOKEN>" http://<RAG_API_ENDPOINT> - if HTTP 200 and sensitive data is returned, the vulnerability is present.'}] [2]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include separating the JWT secrets used for LibreChat user sessions and the RAG API service authentication to prevent token reuse across services.

Additionally, implementing audience claim validation in JWT tokens can prevent tokens issued for one service from being accepted by another.

If you are using Docker Compose, employ separate environment files for each service to restrict access to secrets.

Contact the vendor or maintainers for official patches or updates, as no official patch was available at the time of disclosure.

Note that default deployments are reportedly no longer externally exploitable due to SSRF fixes, but internal network access still poses a risk.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart