Description

Quivr versions through 0.0.322 fail to validate chat ownership in the GET /chat/{chat_id}/history, DELETE /chat/{chat_id}, and POST /chat/{chat_id}/question/answer endpoints. Authenticated attackers can read other users' conversation histories including private knowledge base content, delete arbitrary chats, and inject fabricated messages into other users' conversations.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-28T20:20:19.823Z",
  "pubdate": "2026-08-28T20:20:19.823Z",
  "executiveSummary": "Quivr versions through 0.0.322 are susceptible to a critical Broken Object Level Authorization (BOLA) vulnerability. The application fails to properly validate the ownership of chat resources during API interactions, allowing authenticated users to perform unauthorized operations on arbitrary chat histories.\nThe vulnerability allows an attacker to bypass access controls to read sensitive conversation data, delete third-party chats, and inject malicious content into existing user sessions. By manipulating the chat_id parameter in specific API requests, an authenticated attacker can access or modify private knowledge base content associated with other users.\nThe scope of this vulnerability is severe, as it facilitates data exfiltration, unauthorized destruction of user data, and potential integrity compromise of AI-driven interactions. Successful exploitation requires the attacker to possess an authenticated session, but requires no additional special privileges beyond being a registered user within the instance. The lack of server-side ownership verification across the affected endpoints presents a significant risk to confidentiality and integrity within multi-tenant or multi-user deployments of Quivr.",
  "technicalDetails": "The root cause of this vulnerability is a failure in the server-side access control logic, specifically the omission of ownership validation within the backend handlers for the /chat/{chat_id}/history, DELETE /chat/{chat_id}, and POST /chat/{chat_id}/question/answer endpoints. In a secure architecture, the application must verify that the authenticated user's session identifier (typically derived from a JWT or session cookie) is cryptographically or logically associated with the specific chat_id being accessed or modified in the database.\nIn Quivr versions 0.0.322 and earlier, the application processes the {chat_id} parameter directly from the request URI without verifying the cross-reference between the requested resource and the requester's identity. This represents a classic BOLA condition (CWE-285/CWE-639), where the application trusts user-provided identifiers without verifying authorization context.\nThe attack flow proceeds as follows: First, the attacker authenticates as a standard user. Second, the attacker identifies valid chat_ids through enumeration or observation of traffic patterns. Third, the attacker issues a GET request to /chat/{chat_id}/history, triggering the retrieval of arbitrary conversation records, including sensitive knowledge base data. Fourth, the attacker may issue a DELETE request to /chat/{chat_id} to perform unauthorized data destruction. Finally, the attacker can POST a request to /chat/{chat_id}/question/answer to inject fabricated messages into a victim's ongoing session. Because the application logic relies solely on the presence of the ID rather than the ownership relationship, these requests are processed as legitimate interactions.\nThe impact is significant because the injected messages can manipulate the context of a user's session with the LLM, potentially leading to social engineering or the unauthorized extraction of further private information from the connected knowledge base. The vulnerability persists across all deployment environments where authentication is required but authorization is not enforced at the object level, effectively neutralizing the boundaries between user workspaces. No specialized network access is required beyond the ability to reach the API endpoints, and because the application processes these requests at the service layer, they do not trigger standard audit logs for unauthorized access, as the system treats the operations as valid requests performed by an authenticated user."
}