Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-21T21:17:10.143Z",
  "pubdate": "2026-09-21T21:17:10.143Z",
  "executiveSummary": "MaxKB versions 2.0.0 through 2.9.2 are susceptible to an Improper Access Control vulnerability that allows low-privileged workspace members to execute unauthorized tools.\nThe vulnerability originates from a failure in the dispatch path to re-validate WorkspaceUserResourcePermission grants when interacting with agent or workflow dispatchers.\nAn attacker possessing basic workspace member privileges can bind restricted identifiers—specifically tool_ids, skill_tool_ids, or mcp_tool_ids—to their own requests, effectively bypassing intended authorization boundaries.\nThe primary risk involves unauthorized data exfiltration and credential exposure, as the execution process automatically decrypts server-side init_params associated with the tool.\nThis allows a malicious actor to retrieve sensitive credentials that were meant to be restricted to authorized users or roles.\nExploitation requires no elevated privileges beyond standard workspace membership and is facilitated by the inconsistent enforcement of security policies across different application execution paths.\nThe vulnerability represents a critical failure in the application's authorization framework, as the dispatch layer relies on implicit trust rather than enforcing explicit per-tool permissions.",
  "technicalDetails": "The vulnerability exists within the MaxKB request dispatch architecture, specifically affecting the agent and workflow execution routes. In MaxKB, tools are governed by WorkspaceUserResourcePermission, which is designed to restrict access based on user role assignments.\nWhile dedicated tool routes correctly validate these permissions before execution, the agent and workflow dispatch paths fail to replicate this authorization check. When a request is routed through the dispatcher, the system neglects to verify if the requesting user possesses the necessary permissions for the provided tool identifiers.\nThe attack flow begins when a low-privileged workspace member identifies a tool_id, skill_tool_id, or mcp_tool_id that is otherwise restricted. The attacker crafts a request payload that includes these forbidden identifiers in the tool binding parameters. Because the dispatch path lacks a re-verification mechanism, the request is accepted by the processing logic.\nUpon receiving the request, the backend initiates the tool execution process. A critical security flaw occurs during this phase: the system automatically proceeds to decrypt server-side init_params associated with the tool. These parameters frequently contain sensitive data, including API keys, authentication tokens, and secret configurations that the tool requires to function. Because the security check was skipped at the dispatch level, the attacker successfully triggers the decryption routine.\nConsequently, the sensitive credentials are decrypted in memory and returned as part of the execution response. The attacker effectively performs a privilege escalation by accessing resources that are cryptographically and administratively protected from their role. This mechanism effectively turns the tool execution engine into an oracle for sensitive credential retrieval.\nThe flaw affects all versions from 2.0.0 to 2.9.2. It is characterized by an architectural inconsistency where the enforcement logic is isolated to specific entry points, leaving the dispatchers vulnerable to manipulation. The lack of centralized, middleware-based authorization enforcement at the controller or service level ensures that any bypass of the primary route effectively nullifies the entire security posture regarding tool access.\nThere is no requirement for external network access or complex social engineering; the attack is conducted entirely through the application's legitimate API interfaces, making it difficult to detect via signature-based network intrusion detection systems without deep application-layer inspection."
}