Description

MaxKB is an open-source AI assistant for enterprise. In 2.7.0 through 2.10.4-lts, POST /chat/api/{application_id}/chat/{chat_id}/share_chat verifies that a conversation exists but does not verify that it belongs to the authenticated chat_user_id or to the application bound to the caller's token. An attacker with any chat token and a known victim chat_id can create an unauthenticated public ChatShareLink exposing the victim's conversation and can create PublicFileAccess state that makes associated files retrievable without credentials, with no available revoke path. No fixed version is available as of this review.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-21T21:17:12.623Z",
  "pubdate": "2026-09-21T21:17:12.623Z",
  "executiveSummary": "MaxKB versions 2.7.0 through 2.10.4-lts suffer from an Insecure Direct Object Reference (IDOR) vulnerability located within the share chat functionality.\nThe vulnerability type is broken access control, specifically regarding the failure to validate authorization for sensitive API endpoints.\nThe impact is critical: an attacker with a valid low-privilege chat token can bypass access controls to expose private conversations and associated sensitive files belonging to any other user or application within the system.\nBy manipulating the chat_id parameter in the POST /chat/api/{application_id}/chat/{chat_id}/share_chat endpoint, an attacker can force the system to generate a public link for arbitrary conversations.\nThis results in the unauthorized public disclosure of private AI assistant logs and potential exfiltration of associated files through PublicFileAccess state.\nThere is currently no mechanism to revoke these publicly exposed links, leading to a permanent security breach of the exposed data.\nThe vulnerability requires an authenticated chat token, but no specific administrative privileges are necessary, allowing any registered user to perform cross-tenant data exposure.",
  "technicalDetails": "The vulnerability resides in the backend API controller handling the POST /chat/api/{application_id}/chat/{chat_id}/share_chat request. The root cause is a flaw in the business logic validation process: while the application confirms the existence of the chat_id provided in the URI, it fails to perform a secondary ownership check to verify that the specified chat_id is legitimately linked to the authenticated user's session or the application scope associated with the provided API token.\nDuring the exploitation flow, an attacker authenticates with their own valid, low-privilege chat token. Upon reaching the targeted endpoint, the attacker provides a victim's known chat_id. The application's backend retrieves the chat record based solely on the identifier provided in the URL path. Because the authorization logic lacks an object-level permission check, the system processes the share request as if the attacker were the authorized owner of the chat thread.\nThe exploitation yields two primary security failures. First, the application generates a public ChatShareLink. This link creates an entry in the system that allows anyone with the URL to view the contents of the victim's conversation, effectively circumventing authentication and confidentiality controls.\nSecond, the vulnerability triggers an unintended PublicFileAccess state. When a chat contains associated documents or data files, the process of creating the public share link exposes these underlying objects to unauthenticated requests. By transitioning these files to a public state, the system makes them retrievable without credentials via direct file access URLs.\nThe attack is exacerbated by the lack of a revocation or lifecycle management mechanism for the created share links. Once the link is generated by the attacker, the data remains exposed indefinitely, providing no path for remediation or access reversal for the victim whose data was compromised.\nThe vulnerability is present across MaxKB versions 2.7.0 through 2.10.4-lts. Because this is a logical flaw in the API verification layer, it is exploitable over any network interface that has access to the MaxKB API, regardless of the complexity of the internal architecture. There are no known patches currently available to resolve this authorization failure."
}