CVE-2026-77517 in MaxKB
Summary
by MITRE • 09/22/2026
MaxKB is an open-source AI assistant for enterprise. From version 2.0.0 through 2.10.2-lts, document and paragraph operate routes authorize only knowledge_id in the request path, then query the target Document by document_id or Paragraph by paragraph_id without confirming that the object belongs to that knowledge base. A normal workspace user with a known victim document or paragraph UUID can use an attacker-owned knowledge-base path to read or modify content in another user's knowledge base. No fixed version is available as of this review.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in MaxKB, specifically affecting versions from 2.0.0 through 2.10.2-lts, represents a critical failure in access control logic known as an Insecure Direct Object Reference or IDOR. This flaw stems from the application's reliance on path parameters for authorization decisions rather than verifying object ownership against user context. The system is designed to manage enterprise knowledge bases where documents and paragraphs are organized within specific knowledge base containers. When a user interacts with these resources, the API routes initially check if the provided knowledge_id in the request URL matches an authorized resource. However, this validation step is superficial because it does not cross-reference the target document or paragraph identifier against the ownership records of that specific knowledge base. Consequently, the application assumes that any valid UUID for a document or paragraph belongs to the specified knowledge base without performing a secondary integrity check to ensure the object actually resides within that container's scope.
This architectural oversight allows an attacker with legitimate access as a normal workspace user to bypass isolation boundaries between different users' data sets. By leveraging a known victim document or paragraph UUID, which can often be discovered through enumeration techniques or leaked metadata, the attacker constructs malicious requests targeting their own knowledge base path but referencing the victim's resource identifiers. Since the backend logic only validates that the request originates from an authenticated user and matches a valid object ID without confirming hierarchical ownership, it processes the read or modification operations successfully. This results in unauthorized data exfiltration where sensitive enterprise information can be viewed by unintended parties, as well as potential data integrity issues if the attacker modifies content within another user's knowledge base. The impact is severe because it undermines the fundamental multi-tenant security model required for any SaaS or on-premise AI assistant platform handling proprietary corporate intelligence.
From a classification perspective, this vulnerability aligns directly with CWE-639: Authorization Bypass Through User-Controlled Key. It also maps to MITRE ATT&CK technique T1078, specifically the Valid Accounts sub-category, as it exploits legitimate credentials to access resources outside their intended scope. The lack of proper object-level authorization checks is a common pitfall in RESTful API design where developers prioritize convenience over security by trusting client-supplied identifiers for both resource location and permission validation. To mitigate this issue, developers must implement strict ownership verification at the database query level or within the service layer logic. Every request involving sensitive resources should include an additional check that confirms the target document or paragraph is explicitly associated with the knowledge base identified in the path parameters and owned by the authenticated user. Until a fixed version is released, administrators can apply compensating controls such as implementing strict input validation on server-side handlers to reject requests where resource ownership does not match the context, although this requires custom code modifications given that no official patch exists at this time.