CVE-2025-69221
Improper Access Control in LibreChat Allows Agent Permission Disclosure
Publication date: 2026-01-07
Last updated on: 2026-01-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| danny_avila | librechat | to 0.8.2-rc2 (exc) |
| danny_avila | librechat | 0.8.2-rc2 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-284 | The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. |
| CWE-862 | The product does not perform an authorization check when an actor attempts to access a resource or perform an action. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-69221 is an access control vulnerability in LibreChat version 0.8.1-rc2 where authenticated users can query and read the permissions of arbitrary agents without proper authorization. Agents in LibreChat have predefined instructions and contexts, and their permissions are meant to be private. However, due to insufficient access control, an attacker who knows or can guess an agent's ID can retrieve sensitive permission information, including which users have access and their permission levels. This is possible because agent IDs are MongoDB ObjectIds, which have a predictable format that can be brute-forced. The vulnerability allows unauthorized disclosure of permission data but does not affect integrity or availability. It was fixed in version 0.8.2-rc2 by enforcing proper permission checks on querying agent permissions. [2, 3]
How can this vulnerability impact me? :
This vulnerability can impact you by allowing an attacker with low privileges to gain unauthorized access to sensitive permission information of agents in LibreChat. The attacker can discover which users have access to private agents, their permission levels (such as owner, editor, viewer), and other related details like user emails and names. Although the attacker cannot modify or disrupt the system, the confidentiality of permission data is compromised, potentially exposing sensitive user and access information that should remain private. [2, 3]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to query agent permissions via the GET `/api/permissions/:resourceType/:resourceId` endpoint using an authenticated user account without proper permissions. Since agent IDs are MongoDB ObjectIds and predictable, an attacker can brute-force or guess valid agent IDs to check if permission data is accessible. Detection commands would involve authenticated HTTP requests to this endpoint with various agent IDs to see if permission data is returned without proper authorization. For example, using curl: `curl -H "Authorization: Bearer <token>" https://<librechat-server>/api/permissions/agent/<agentId>` and checking if permission details are returned even when the user should not have access. Monitoring logs for such unauthorized permission queries or unusual access patterns to this endpoint can also help detect exploitation attempts. [2, 3]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to update LibreChat to version 0.8.2-rc2 or later, where the vulnerability is fixed by enforcing proper access control checks on permission queries. This update introduces middleware that requires users to have the SHARE permission on the resource before they can query or modify permissions, preventing unauthorized access. Additionally, ensure that permission checks are properly enforced on all agent permission query and update endpoints. If updating immediately is not possible, restrict access to the affected API endpoints and monitor for suspicious activity. [2, 3]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows unauthorized disclosure of sensitive permission data, including user emails and names associated with private agents. This unauthorized access to personal and permission-related information could lead to non-compliance with data protection regulations such as GDPR and HIPAA, which require strict access controls and protection of personal data confidentiality. Therefore, the vulnerability poses a risk to compliance with these standards by enabling unauthorized users to access confidential user permission information. [2, 3]