CVE-2026-33265
JWT Authentication Bypass in LibreChat API and RAG API
Publication date: 2026-03-18
Last updated on: 2026-03-24
Assigner: MITRE
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-669 | The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability in LibreChat version 0.8.1-rc2 is an authentication bypass issue caused by improper access control in the Retrieval-Augmented Generation (RAG) API.
LibreChat uses the same JSON Web Token (JWT) secret for both user session management and the RAG API service-level authentication. This means that a logged-in user obtains a JWT token that is valid for both the LibreChat API and the RAG API.
Because the RAG API does not enforce additional access restrictions such as audience claims or separate secrets, an authenticated LibreChat user can reuse their session JWT token to authenticate directly against the RAG API.
This allows the attacker to read, replace, delete, or upload documents in the RAG API, which is normally intended to be accessed only internally.
How can this vulnerability impact me? :
If exploited, this vulnerability allows an authenticated LibreChat user to gain unauthorized access to the RAG API.
- Read all stored documents within the RAG API.
- Replace or delete existing documents.
- Upload new documents to the RAG API.
Since the RAG API typically requires internal network access, exploitation requires either internal access or chaining with another vulnerability to reach the API.
Overall, this can lead to data confidentiality, integrity, and availability issues within the affected environment.
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 verifying if a JWT token obtained from logging into LibreChat can be reused to access the RAG API endpoints without additional authentication.'}, {'type': 'paragraph', 'content': 'A practical detection method involves the following steps:'}, {'type': 'list_item', 'content': 'Log into LibreChat and obtain the JWT token.'}, {'type': 'list_item', 'content': 'Use the JWT token in the Authorization header to send a request to the RAG API endpoint (e.g., /ids).'}, {'type': 'list_item', 'content': 'If the request returns HTTP 200 OK with data, the vulnerability is present.'}, {'type': 'paragraph', 'content': 'Example command using curl:'}, {'type': 'list_item', 'content': 'curl -H "Authorization: Bearer <JWT_TOKEN>" http://<RAG_API_HOST>/ids'}, {'type': 'paragraph', 'content': 'If the response is HTTP 401 Unauthorized without the token and HTTP 200 OK with the token, it confirms the improper access control.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Use separate JWT secrets for LibreChat user sessions and the RAG API service authentication to prevent token reuse.
- Implement audience (aud) claims in JWT tokens and validate them on both LibreChat and RAG API sides to restrict token usage to intended services.
- Separate environment configuration files per service, especially in Docker Compose setups, to restrict secret exposure.
- Limit RAG API access to internal networks only and ensure no external exposure.
- Contact the vendor for an official fix and apply it once available.