MaxKB Workspace Permission Bypass via Agent/Workflow Tool Dispatch
First seen Sep 22, 2026 · Updated Sep 22, 2026 · CVSS 5.4
A low-privileged workspace member in MaxKB can bypass tool-level access restrictions by referencing a denied tool's identifier through agent or workflow dispatch paths instead of the dedicated tool routes. Because the dispatch path fails to re-check per-tool permissions, the attacker can execute the restricted tool and obtain decrypted server-side credentials (init_params) associated with it. This is a genuine authorization design flaw with a moderate CVSS score, limited to authenticated internal users within a shared workspace.
Technical Analysis
MaxKB enforces tool access via WorkspaceUserResourcePermission on its dedicated tool invocation routes, but the agent/workflow dispatch mechanism accepts tool_ids, skill_tool_ids, or mcp_tool_ids directly without reapplying the same permission check. A low-role user can therefore craft an agent or workflow definition that references a tool identifier they are not authorized to call directly, and the dispatch path will execute it anyway. During execution, the tool layer decrypts init_params (which can include API keys, MCP server credentials, or other secrets) server-side, and these are returned to the caller, resulting in credential exfiltration. This crosses a trust boundary between workspace-level authorization and the agent/workflow execution engine, effectively turning tool binding into a privilege escalation and secrets-disclosure vector.
Affected Systems
MaxKB; protocols: MCP
Detection Signatures
- Look for agent/workflow definitions containing tool_ids, skill_tool_ids, or mcp_tool_ids referencing tools outside the creator's granted WorkspaceUserResourcePermission set.
- Audit logs showing tool execution via /agent/ or /workflow/ dispatch endpoints for tools that the same user was denied via direct tool routes.
- Unexpected decrypted init_params or credential values appearing in agent/workflow execution responses or logs.
- Multiple low-privilege accounts invoking the same restricted tool_id exclusively through dispatch paths rather than direct tool calls.
Remediation Steps
- 1
Enforce permission checks in dispatch path
Apply the same WorkspaceUserResourcePermission validation used in dedicated tool routes to the agent and workflow dispatch execution paths before resolving or executing any tool_ids, skill_tool_ids, or mcp_tool_ids.
- 2
Avoid returning decrypted secrets to callers
Ensure init_params decryption occurs strictly server-side for internal tool invocation and is never included in responses returned to the calling user or agent context.
- 3
Audit workspace tool bindings
Review existing agents and workflows for tool references bound by users without direct access, and revoke or re-validate those bindings.
- 4
Upgrade when patch available
Monitor MaxKB releases for a fix beyond 2.9.2 and apply it promptly; until then, restrict workspace member roles and tool credential scope as a compensating control.
- 5
Least-privilege credential scoping
Scope init_params/credentials per tool as narrowly as possible so that even if disclosed, the blast radius of leaked secrets is minimized.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.