Description

Blinko 1.8.7 contains an authorization bypass (IDOR) vulnerability in multiple tRPC procedures (message.list, message.update, message.delete, message.clearAfter in server/routerTrpc/message.ts and conversation.clearMessages in server/routerTrpc/conversation.ts). Although these procedures require authentication, they query the database by caller-supplied conversation or message ID without verifying that the resource belongs to the requesting account. Any authenticated user can therefore read another user's full AI chat history, modify individual message content, and delete or wipe entire conversations by enumerating sequential integer IDs.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-04T15:17:41.547Z",
  "pubdate": "2026-09-04T15:17:41.547Z",
  "executiveSummary": "Blinko version 1.8.7 is affected by an Insecure Direct Object Reference (IDOR) vulnerability resulting from insufficient server-side access control validation within multiple tRPC procedures.\nThe vulnerability resides in message and conversation management endpoints where the application relies on caller-supplied identifiers without verifying resource ownership.\nThis flaw allows any authenticated user to perform unauthorized operations, including reading, modifying, or deleting the private chat histories of other users.\nThe impact is critical, as it leads to a total compromise of data confidentiality and integrity for user-generated content.\nExploitation is trivial, requiring only a valid user account and the ability to enumerate sequential integer IDs to target resources across the application.\nThe vulnerability effectively grants any authenticated attacker the capability to exfiltrate full conversation histories and perform administrative-level destructive actions against arbitrary users.",
  "technicalDetails": "The vulnerability is rooted in a failure to perform adequate authorization checks within the server/routerTrpc/message.ts and server/routerTrpc/conversation.ts modules. While these tRPC procedures correctly require authentication, they fail to implement ownership validation logic when processing database queries.\nSpecifically, the procedures message.list, message.update, message.delete, message.clearAfter, and conversation.clearMessages accept user-supplied message or conversation identifiers directly from the client request. The backend code uses these identifiers to query the database and perform CRUD operations without confirming that the requested object corresponds to the currently authenticated user's session ID.\nThe attack flow proceeds as follows: 1. An attacker initiates a valid session with their own legitimate account. 2. The attacker identifies the tRPC API endpoints responsible for message and conversation management. 3. Because the application utilizes sequential integer IDs for messages and conversations, the attacker crafts a series of requests targeting identifiers outside their own assigned range. 4. Due to the lack of ownership verification in the tRPC router logic, the database executes the requested operations—be it SELECT, UPDATE, or DELETE—on the resource provided by the attacker, effectively bypassing the intended access constraints.\nThe use of predictable, sequential identifiers exacerbates the risk, enabling an attacker to systematically iterate through the entire message and conversation dataset of the instance. The post-exploitation impact includes the exfiltration of sensitive, private AI-generated chat logs, the modification of content to alter context or inject malicious information, and the permanent destruction of user data through the clear/delete procedures.\nThis vulnerability is present in Blinko 1.8.7 and represents a critical architectural oversight in the design of the authorization layer, where the trust model incorrectly assumes that the possession of an object ID implies authorized access to that object.\nThe network exposure is identical to the application's tRPC interface. Because the vulnerability exists within the application logic layer, standard network-level protections are ineffective, as all requests appear valid and authenticated to the server."
}