CVE-2026-77518 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 workspace user who knows another user's active MCP tool_id in the same workspace can retrieve the hidden tool through the tool-detail route because it does not apply the per-resource authorization used by the list route. The response includes Tool.code, which may contain MCP server configuration and headers, and an attacker who can create or edit an attacker-owned workflow can place the same foreign mcp_tool_id in a workflow mcp-node so workflow debug uses the owner's MCP configuration without verifying permission to use that tool. No fixed version is available as of this review.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
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 object-level access control, specifically affecting multi-tenant workspace environments where multiple users share resources under different privilege levels. This flaw allows an authenticated user with standard workspace permissions to bypass intended security boundaries by exploiting inconsistencies between how resource lists are secured versus how individual resource details are accessed. The core technical issue lies in the tool-detail endpoint, which retrieves comprehensive information about a specific Management Connector Protocol (MCP) tool without verifying that the requesting user has explicit authorization for that particular tool instance. While the list route correctly implements per-resource authorization checks to filter results based on user ownership or permissions, the detail route fails to perform this validation, relying instead on the assumption that knowledge of an identifier is sufficient access control. This architectural inconsistency creates a direct path for unauthorized data retrieval and potential configuration exposure within shared enterprise environments.
The operational impact of this vulnerability extends beyond simple information disclosure due to the nature of MCP tool configurations. The response payload from the compromised detail route includes sensitive fields such as Tool.code, which often contains embedded server configurations, authentication headers, API keys, or other credentials required for external service integration. An attacker who successfully exploits this flaw can extract these secrets, effectively gaining access to third-party services configured by legitimate users within the same workspace. This constitutes a severe confidentiality breach and potentially enables further attacks against downstream systems that trust the compromised credentials. The risk is amplified in enterprise settings where MCP tools are used for critical business operations, as exposure of connection strings or API tokens can lead to data exfiltration, service disruption, or lateral movement across networked services dependent on those integrations.
Furthermore, the vulnerability enables a more sophisticated attack vector involving workflow automation and execution context manipulation. An attacker with the ability to create or edit workflows within the workspace can embed a foreign mcp_tool_id into an MCP node of their own workflow definition. When this maliciously configured workflow is executed in debug mode by its owner, the system attempts to invoke the specified tool using the owner's credentials and configuration context rather than isolating the execution environment. Because the underlying framework does not verify whether the current user has permission to use the referenced foreign tool during runtime, the attacker effectively hijacks the victim's MCP session. This allows the attacker to execute arbitrary operations under the guise of the legitimate user, potentially leading to unauthorized data modification, deletion, or exfiltration through trusted integrations that would otherwise be protected by role-based access controls.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and specifically CWE-639 Authorization Bypass Through User-Controlled Key, as the attacker leverages knowledge of another user's resource identifier to bypass authorization checks. In terms of offensive security frameworks, this behavior maps to ATT&CK technique T1078 Valid Accounts, where an adversary uses legitimate credentials or access patterns to move laterally and escalate privileges within a system. The exploitation chain also reflects aspects of T1530 Data from Information Repositories if the attacker proceeds to exfiltrate sensitive data obtained through the compromised MCP configurations. These mappings highlight that while the initial entry point is relatively simple, the subsequent impact involves complex privilege escalation and context manipulation typical of advanced persistent threats targeting enterprise AI assistants.
Mitigation strategies for this vulnerability must address both the immediate access control flaw and the broader architectural assumptions regarding resource isolation. Since no fixed version was available at the time of review, organizations relying on MaxKB should implement compensating controls such as strict network segmentation to limit exposure of internal management interfaces and enforce multi-factor authentication for all workspace users to reduce the risk of credential compromise leading to identifier enumeration. Administrators should also audit workflow definitions regularly to detect any unauthorized inclusion of foreign tool IDs in MCP nodes. Additionally, implementing runtime permission checks within the workflow execution engine is critical; the system must validate that the user initiating a debug session or workflow run has explicit rights to invoke every referenced external tool before allowing the operation to proceed. Until an official patch is released by the vendor, limiting workspace membership to trusted individuals and disabling public-facing access to MaxKB instances are essential steps to minimize the attack surface associated with this authorization bypass flaw.