LibreChat CVE-2026-44654

The attacker must hold editor-level access to at least one shared agent within the target LibreChat instance - this is a low-privilege authenticated role (CVSS PR:L confirmed). The target file must have been uploaded or reused by the owner across multiple agents: at minimum one shared agent (to which the attacker has editor access) and one or more private agents (to which the attacker has no access). No special non-default configuration is required beyond the shared-agent collaboration feature being in use, which is a standard LibreChat deployment pattern. Exploitation is limited by the requirement for prior editor-role authentication; unauthenticated or viewer-role users cannot trigger the vulnerable endpoint. The victim's private agents must reference the same file_id for the cross-agent integrity impact to materialize.

The CVSS 4.0 base score of 5.7 reflects a moderate severity, with the most significant signals being VI:H (High integrity impact) and VA:H (High availability impact) against the vulnerable component, meaning data is permanently destroyed and dependent functionality is broken. Attack complexity is Low (AC:L) and no special attack requirements exist (AT:N), but Low Privileges are required (PR:L) - the attacker must hold editor access to a shared agent, which limits the attack surface to authenticated collaborators. The E:P modifier confirms exploit proof-of-concept exists, elevating the practical risk above theory. No EPSS score was provided in the source data. The vulnerability is not listed in CISA KEV, indicating no confirmed widespread active exploitation at time of analysis. The real-world risk is material for multi-user LibreChat deployments where agents are shared with external collaborators: a malicious or compromised editor can silently sabotage an owner's private agent ecosystem without any access to those private agents. The integrity loss is irreversible without file restoration from backup.

An attacker with editor access to a shared LibreChat agent inspects the agent's associated file_id values and issues a DELETE /api/files request via the API using those identifiers. Because the deletion is processed globally rather than scoped to the shared agent, the file is purged from the backend store entirely. The owner's private agents that referenced the same file_id now silently fail when attempting to resolve the file - breaking the owner's workflows without generating any access alert or notification. A proof-of-concept exists, making this scenario straightforward for any authenticated collaborator to execute.