CVE-2025-41258
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
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| librechat | librechat | 0.8.1 |
Helpful Resources
Exploitability
| 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.