CVE-2026-79917 in MaxKB
Summary
by MITRE • 09/21/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in MaxKB versions 2.7.0 through 2.10.4-lts represents a critical failure in access control logic within the application's chat sharing mechanism. Specifically, the endpoint POST /chat/api/{application_id}/chat/{chat_id}/share_chat is designed to generate share links for conversations. However, the implementation fails to enforce proper authorization checks regarding ownership and association. While the system correctly verifies that the specified conversation exists in the database, it neglects to validate whether the authenticated user initiating the request actually owns the chat or has a legitimate relationship with the application associated with that chat. This oversight allows any actor possessing a valid chat token for any application to manipulate sharing settings for conversations they do not own, provided they can guess or obtain the target chat_id.
This architectural flaw leads directly to severe confidentiality breaches and unauthorized data exposure. An attacker leveraging this vulnerability can create an unauthenticated public ChatShareLink that exposes the contents of a victim's conversation. Since the verification logic does not cross-reference the authenticated user identity with the owner of the chat, the system treats any request from a valid token as authorized for sharing operations on arbitrary chats. Furthermore, the vulnerability extends to file attachments associated with these conversations. The attacker can set the state of associated files to PublicFileAccess, rendering them retrievable without credentials. This effectively bypasses authentication controls that should protect sensitive documents and data shared within private enterprise communications.
The operational impact is compounded by the lack of a revocation mechanism for these unauthorized shares. Once an attacker creates a public share link or sets files to public access state, there is no available path to revoke this exposure through normal administrative functions. This permanence increases the risk profile significantly, as sensitive information remains accessible indefinitely unless manually removed from the database or if the application undergoes a complete data purge. For enterprise environments relying on MaxKB for internal knowledge management and secure communication, this vulnerability undermines trust in the platform's ability to isolate tenant data and protect user privacy.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control, as the system fails to restrict resources according to authorized users' privileges. It also relates to CWE-639 Authorization Bypass Through User-Controlled Key, where the chat_id serves as an unvalidated key that determines access scope without verifying ownership. In terms of attack vectors, this corresponds to MITRE ATT&CK technique T1078 Valid Accounts, as exploitation requires a valid token but does not require high privileges or specific user roles beyond basic authentication. The ability to escalate from a standard authenticated state to full data exfiltration highlights the severity of the authorization gap.
Mitigation strategies are currently limited due to the absence of a fixed version in the vendor's release cycle. Organizations running affected versions must implement compensating controls at the network or application gateway level if possible, such as restricting access to the specific API endpoint based on IP reputation or rate limiting to reduce exposure windows. Immediate manual audits of shared chat links and file permissions are recommended to identify and remove any unauthorized public shares that may have been created by attackers exploiting this flaw in earlier deployments. Until a patched version is released, treating all shared content as potentially compromised is the most prudent security posture for affected enterprises.