CVE-2026-77516 in MaxKB
Summary
by MITRE • 09/22/2026
MaxKB is an open-source AI assistant for enterprise. From version 2.0.0 through 2.9.2, a lowest-role workspace member denied access to a tool by WorkspaceUserResourcePermission can still bind its identifier through tool_ids, skill_tool_ids, or mcp_tool_ids and execute it through the agent or workflow dispatch path. The dispatch path does not reapply the per-tool grant enforced by dedicated tool routes, and tool execution decrypts server-side init_params, allowing the caller to receive credentials carried by the denied tool. 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 versions 2.0.0 through 2.9.2 represents a critical authorization bypass within an enterprise-grade open-source AI assistant platform. The core issue stems from a discrepancy between the enforcement mechanisms used for different operational paths within the application architecture. Specifically, while dedicated tool routes correctly enforce per-tool grants defined by WorkspaceUserResourcePermission to restrict access based on user roles, this security control is not reapplied when tools are invoked through alternative execution pathways such as agent dispatch or workflow orchestration engines. This architectural inconsistency allows a workspace member with the lowest privilege level, who has been explicitly denied permission for specific tools via their role-based permissions, to circumvent these restrictions by binding the tool identifier directly within configuration parameters like tool_ids, skill_tool_ids, or mcp_tool_ids.
From a technical perspective, the flaw lies in the lack of idempotent authorization checks during the execution phase of agents and workflows. When an agent or workflow is dispatched, it processes the list of tools to be executed without re-verifying whether the initiating user retains valid permissions for each specific tool listed. This oversight effectively nullifies the access control policies established at the workspace level. The attacker leverages this gap by constructing a request that includes identifiers for restricted tools within these binding parameters. Because the dispatch path does not perform a secondary authorization check against the WorkspaceUserResourcePermission table, the system proceeds to execute the command as if the user had legitimate access rights.
The operational impact of this vulnerability is severe due to the nature of how AI agents interact with external systems and sensitive data. Upon execution, the tool handler decrypts server-side initialization parameters known as init_params. These parameters frequently contain credentials, API keys, or other authentication tokens required for the tool to function against backend services. By exploiting this flaw, an unauthorized user can trigger the decryption process and receive these sensitive credentials in the response payload. This transforms a simple authorization bypass into a potential credential theft scenario, allowing low-privilege users to gain access to external resources protected by those stolen secrets, thereby escalating their privileges significantly beyond what was intended by the system administrators.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where an actor obtains elevated permissions or accesses restricted functions without proper authorization checks. Furthermore, it maps to MITRE ATT&CK technique T1078, Valid Accounts, as a low-level user leverages valid but insufficiently scoped credentials to access resources they are not permitted to use. The specific mechanism of bypassing controls through alternative execution paths also reflects aspects of CWE-926, Improper Export of Data with Identifiable Security Information, given that the decrypted init_params expose sensitive configuration data directly to the client side during an unauthorized operation.
Mitigation strategies for this vulnerability must focus on enforcing consistent authorization checks across all entry points and execution contexts within the application. Developers should implement a centralized authorization middleware or service layer that validates WorkspaceUserResourcePermission before any tool is executed, regardless of whether it is called via direct routes or through agent workflows. This ensures that every invocation undergoes the same rigorous permission verification process. Additionally, sensitive data such as credentials stored in init_params should be handled with extreme care; they should never be decrypted and returned to the client unless there is a verified, explicit authorization for that specific action. Until an official patch is released by the MaxKB maintainers, administrators are advised to restrict workspace member roles strictly, monitor agent execution logs for unusual patterns involving tool bindings, and consider isolating high-privilege tools from general workflow configurations to minimize the attack surface available to lower-level users.