LibreChat EUVD-2026-39461

Exploitation requires the attacker to hold a valid authenticated session (registered user account) on the target LibreChat instance - exploitation by unauthenticated parties is not possible. Beyond authentication, the attacker must obtain or guess a valid MongoDB ObjectID (messageId) belonging to another user; ObjectIDs are 12-byte hex strings encoding timestamp, machine ID, process ID, and counter, making random guessing impractical. Exploitation is therefore limited to scenarios where messageIds are observable: shared conversation contexts, API response interception, or privileged log access. Environments where all users are equally trusted (single-user or fully trusted-team deployments) face negligible practical risk. The vulnerability does not require any non-default configuration - the affected endpoint is present in all standard deployments prior to the fix.

The provided CVSS 3.1 score of 5.3 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N) accurately reflects the attack complexity: an authenticated user must obtain a victim's messageId, which is not trivially enumerable. Real-world risk is meaningful in multi-tenant or shared LibreChat deployments where multiple users interact and messageIds may be observable via logs, shared conversations, or API responses. No EPSS data was supplied, and there is no KEV listing or known public POC, suggesting this is not currently being mass-exploited. The I:H metric is appropriate because successful exploitation causes permanent, irrecoverable data loss - deleted messages cannot be restored. Confidentiality and availability are both N per CVSS convention, as no data is disclosed and the service itself remains operational. The primary risk is targeted sabotage or harassment within a shared deployment rather than broad opportunistic exploitation.

An authenticated attacker on a shared LibreChat instance (e.g., a team or public deployment) obtains a colleague's messageId through a shared conversation view, API response inspection, or server-side log access. The attacker then sends DELETE /api/messages/{their_own_conversationId}/{victim_messageId}, which passes middleware validation (the conversationId is legitimately theirs) and silently deletes the victim's message at the database level with no recovery path. No public POC has been identified, but the logic is straightforward enough that any developer-level user could replicate it from the advisory description.