Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-09-21T21:17:10.477Z",
  "pubdate": "2026-09-21T21:17:10.477Z",
  "executiveSummary": "MaxKB versions 2.10.2-lts and earlier are susceptible to an improper authorization vulnerability concerning Model Context Protocol (MCP) tool configurations.\nThe vulnerability allows an authenticated workspace user to bypass per-resource access controls, enabling the unauthorized retrieval of sensitive metadata and configuration details belonging to other users within the same workspace.\nBy targeting the tool-detail route, an attacker can extract Tool.code, which potentially contains internal MCP server configurations, API keys, and custom headers.\nThis information disclosure facilitates a downstream exploitation chain where an attacker can integrate the discovered tool_id into their own malicious workflows.\nWhen these workflows are executed, the system fails to re-validate the attacker's permissions to utilize the foreign tool, effectively resulting in unauthorized execution of the victim's MCP configurations.\nThe primary risk involves the compromise of sensitive credentials managed within the MCP framework and the potential for lateral movement or service abuse via authorized tool integrations.\nExploitation requires the attacker to be an authenticated user within the target workspace and to possess knowledge of a valid, active mcp_tool_id belonging to another user.",
  "technicalDetails": "The root cause of this vulnerability lies in a broken object-level authorization mechanism within the MaxKB API architecture. While the application implements appropriate access controls on the tool listing endpoints, the specific tool-detail route fails to perform a verification check against the requesting user's permissions for the targeted resource.\nThe vulnerability is triggered by a direct request to the tool-detail route. Because the backend does not enforce per-resource ownership validation, an attacker who identifies a valid mcp_tool_id can query the details of that tool regardless of its ownership. The response generated by this endpoint returns a JSON object containing the Tool.code field. This field is critical, as it often encapsulates proprietary configuration strings, environment-specific secrets, and sensitive HTTP headers used for authenticating with external MCP servers.\nThe attack flow proceeds in two distinct phases. First, the attacker identifies a target mcp_tool_id. This is often achievable via enumeration if the tool IDs follow predictable patterns or are leaked through shared logs or other information disclosure points. Second, once the tool configuration is obtained, the attacker exploits the workflow engine. MaxKB allows users to create and edit workflows consisting of various nodes. An attacker can construct a workflow containing an 'mcp-node' and manually populate the mcp_tool_id field with the stolen identifier.\nThe critical failure occurs during the workflow debug or execution phase. The system processes the node's task based on the provided mcp_tool_id without verifying that the authenticated user initiating the workflow is the authorized owner of the referenced MCP tool. Consequently, the workflow runner executes the request using the victim's underlying MCP configuration, including their authentication headers. This allows the attacker to proxy requests through the victim’s configured environment, effectively bypassing the intended security boundaries. The impact is significant as it grants the attacker the ability to interact with external services or private APIs as if they were the legitimate owner of the MCP tool, leading to unauthorized data access or unauthorized actions within those integrated systems."
}