Description

Cheshire Cat AI's GET /memory/collections/{collection_id}/points endpoint fails to apply per-user filtering when retrieving episodic memory points. Authenticated attackers with MEMORY:READ permission can retrieve all users' stored conversation messages and personal data by paginating through the collection using the offset cursor.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-03T13:06:20.883Z",
  "pubdate": "2026-09-03T13:06:20.883Z",
  "executiveSummary": "The Cheshire Cat AI framework contains a critical Broken Access Control vulnerability within its episodic memory management subsystem. Specifically, the GET /memory/collections/{collection_id}/points endpoint fails to enforce per-user scope validation during data retrieval operations. This flaw allows authenticated users possessing the MEMORY:READ permission to bypass multi-tenancy boundaries and access sensitive data belonging to other users.\nThe impact is significant, as it facilitates unauthorized access to the entire history of stored conversation messages and associated personal information. An attacker can systematically exfiltrate data by iterating through memory collections using the exposed offset cursor. The vulnerability poses a severe risk to data confidentiality and privacy, effectively negating the isolation mechanisms expected in a multi-user AI environment. Exploitation is straightforward, requiring only standard authentication and the specific read permission, making this an attractive target for internal threats or compromised accounts seeking to harvest long-term memory data.",
  "technicalDetails": "The root cause of this vulnerability lies in an insecure implementation of the access control layer within the /memory/collections/{collection_id}/points endpoint handler. While the system authenticates the request, it fails to perform server-side filtering to restrict the query results to the memory points owned by or associated with the authenticated user's ID. Instead, the backend logic executes a broad query against the vector database or memory storage provider, returning all points within the specified collection regardless of ownership metadata.\nThe attack flow proceeds as follows: First, an authenticated attacker with MEMORY:READ privileges identifies the target collection identifier. Second, the attacker sends a series of GET requests to the vulnerable endpoint, utilizing the 'offset' and 'limit' parameters to paginate through the memory collection. Because the server-side controller lacks a 'WHERE user_id = <authenticated_user>' clause (or equivalent logical partition enforcement), the database engine returns memory points globally stored within that collection.\nThe exploitation method relies on the predictable nature of the pagination cursor. By incrementing the offset parameter, an attacker can sequentially scrape every stored conversation, user intent, and metadata attribute present in the memory collection. The vulnerable component is the memory retrieval service module responsible for interfacing with the episodic memory storage backend. As the system design assumes that access to the collection implies authorized access to all content therein, the absence of identity-aware data filtering represents a fundamental failure in the application's authorization logic.\nPost-exploitation impact includes the full disclosure of private user conversations, extraction of system-level prompt injection secrets if stored in memory, and potential reconstruction of user behavior patterns. Since this data is persistent, the vulnerability exposes historical data rather than just real-time interaction. The vulnerability is accessible over any network interface where the API is exposed, and there are no additional obfuscation or rate-limiting mechanisms mentioned that would prevent a programmatic, automated scrape of the entire memory database."
}