CVE-2026-77525 in MaxKB
Summary
by MITRE • 09/21/2026
MaxKB is an open-source AI assistant for enterprise. In 2.10.2-lts and earlier, management chat-record routes authorize the path application_id but load records using global chat_id and chat_record_id values without confirming that the chat belongs to the authorized application. A normal user in the same workspace who knows the chat_id of a persisted non-debug record for a victim's published application can place it under a separate attacker-owned application path to read victim chat records. An attacker with an owned knowledge base and document can also use add_knowledge to copy victim answers while updating the victim record's improve_paragraph_id_list. No fixed version is available as of this review.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in MaxKB versions 2.10.2-lts and earlier represents a critical failure in access control logic, specifically manifesting as an Insecure Direct Object Reference (IDOR) within the application's chat management subsystem. This flaw stems from a fundamental disconnect between authorization checks and data retrieval mechanisms. The system correctly validates that a user has permission to interact with a specific application identified by its unique identifier during route initialization. However, when processing requests for chat records, the backend logic relies exclusively on global identifiers such as chat_id and chat_record_id without cross-referencing these values against the authorized application context established earlier in the request lifecycle. This architectural oversight allows an authenticated user to bypass intended isolation boundaries between different applications within the same workspace, effectively treating distinct data silos as a single shared resource pool where access is determined solely by knowledge of valid object identifiers rather than strict ownership verification.
From an operational perspective, this vulnerability enables significant unauthorized information disclosure and potential integrity violations for enterprise users relying on MaxKB for secure AI interactions. A malicious actor who possesses standard user privileges within the same workspace can exploit this flaw to read sensitive conversation histories belonging to other applications they do not own or have explicit permission to access. By simply knowing the chat_id of a persisted, non-debug record associated with a victim's published application, an attacker can manipulate API endpoints to load and view these records under their own controlled application path. This capability compromises the confidentiality of proprietary discussions, customer interactions, or internal strategic planning stored within those chats. Furthermore, the vulnerability extends beyond passive data exfiltration; it allows for active manipulation of knowledge bases through the add_knowledge endpoint. An attacker with access to a specific document can copy answers from victim records and simultaneously update the improve_paragraph_id_list field associated with those records. This dual capability not only facilitates theft of intellectual property but also introduces risks related to data integrity, as attackers could potentially alter or corrupt existing training data used by the AI models.
The technical root cause is classified under CWE-639, which addresses Authorization Bypass Through User-Controlled Key. The application framework implements a partial authorization check that validates resource ownership at the route level but fails to enforce this constraint during subsequent database queries for related entities like chat records and knowledge base entries. This pattern is particularly dangerous in multi-tenant or workspace-based environments where logical separation of data is paramount. In terms of offensive security frameworks, this behavior aligns with MITRE ATT&CK technique T1078, specifically the Valid Accounts subcategory, as it leverages legitimate user credentials to access resources outside their designated scope without requiring privilege escalation. It also reflects aspects of T1530, Data from Information Repositories, where an attacker accesses stored data that they are not authorized to view due to flawed access control logic rather than a technical exploit of the underlying infrastructure.
Mitigation strategies for this vulnerability must focus on implementing strict object-level authorization checks at every stage of request processing. Developers should ensure that any API endpoint accessing sensitive resources like chat records or knowledge base entries performs a secondary verification step. This involves querying the database to confirm that the requested chat_id and chat_record_id are explicitly linked to an application owned by the authenticated user, rather than relying solely on the initial route parameter validation. Additionally, implementing UUIDs with high entropy for all internal identifiers can reduce the risk of enumeration attacks that facilitate IDOR exploitation. Until a patched version is released, organizations should restrict workspace access to only those users who strictly require it and monitor API logs for unusual patterns of cross-application data retrieval. It is also advisable to disable or limit the add_knowledge functionality for non-administrative users if possible, as this endpoint provides the mechanism for copying sensitive content between applications.