CVE-2026-77520 in MaxKB
Summary
by MITRE • 09/21/2026
MaxKB is an open-source AI assistant for enterprise. In 2.10.2-lts and earlier, a normal user in the same workspace can obtain another user's application_id from the homepage application question-ranking endpoint when the published victim application has ranking activity in the selected date range and the attacker knows or guesses its name, even though direct application detail and debug-open routes deny access. An attacker who can create and publish a workflow application can place the disclosed identifier in an attacker-owned workflow application-node, trigger that workflow, receive output generated by the victim application, and create durable application_chat and application_chat_record rows under the victim application because save and runtime paths do not verify permission to use the referenced application. No fixed version is available as of this review.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability in MaxKB versions 2.10.2-lts and earlier represents a critical failure in access control logic within an enterprise-grade AI assistant platform, specifically affecting multi-tenant workspace environments where multiple users share resources under administrative oversight. The core technical flaw stems from the improper isolation of application identifiers during data retrieval operations on the homepage's question-ranking endpoint. While direct routes for viewing application details and debugging are correctly secured to prevent unauthorized access, this specific ranking endpoint exposes the internal application_id associated with a published workflow if that application has recorded activity within a specified date range. This information disclosure is particularly dangerous because it allows an authenticated attacker who shares a workspace with a victim user to enumerate valid identifiers by leveraging knowledge or guesses of the target application's name combined with temporal data from the ranking endpoint, effectively bypassing the intended security boundaries designed to keep individual applications private within their respective contexts.
Once the attacker obtains the victim’s application_id through this side-channel information leak, they can exploit a subsequent authorization failure in the workflow execution engine. The system fails to verify whether the user initiating a workflow has permission to invoke or interact with the specific application referenced by that identifier. By embedding the stolen application_id into an attacker-controlled workflow node and triggering its execution, the attacker forces the backend runtime to process requests on behalf of the victim’s application context without proper authentication checks at this stage. This lack of object-level access control allows the attacker to generate output using the victim's configured logic and models, effectively hijacking the computational resources and potentially sensitive data processing capabilities associated with that specific AI assistant instance.
The operational impact of this vulnerability extends beyond simple information disclosure or unauthorized computation; it results in significant integrity violations through the creation of persistent artifacts under the victim’s account. Specifically, the exploitation leads to the insertion of durable application_chat and application_chat_record database rows attributed to the victim user rather than the attacker. This not only pollutes the victim's conversation history with maliciously generated content but also potentially skews analytics, ranking metrics, and audit logs associated with their workspace activities. In an enterprise setting, this could lead to reputational damage if inappropriate or misleading AI responses are recorded under a legitimate employee’s account, complicating forensic investigations and trust in the platform’s data integrity. Furthermore, because no fixed version is available as of the review period, organizations relying on these older LTS releases remain exposed to both information leakage and unauthorized resource utilization until an official patch is released by the vendor.
Mitigation strategies for this vulnerability must focus on immediate compensating controls since a software update is not yet provided. Administrators should restrict access to the question-ranking endpoint or disable ranking features entirely if they are not essential for daily operations, thereby eliminating the information disclosure vector. Additionally, implementing strict input validation and authorization checks at the workflow execution layer is critical; specifically, every invocation of an application_id within a workflow node must be validated against the current user’s permissions before processing begins. Organizations should also consider isolating workspaces more rigorously or limiting which users can publish workflows that reference external applications until the vendor releases a corrected version. Regular auditing of chat records and ranking data can help detect anomalous activity indicative of this exploitation, allowing for quicker incident response in environments where patching is delayed due to operational constraints.