CVE-2026-77516: MaxKB: Missing per-tool authorization in the agent and workflow tool-dispatch path
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 toolids, skilltoolids, or mcptoolids 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 initparams, allowing the caller to receive credentials carried by the denied tool. No fixed version is available as of this review.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
A lowest-role workspace member can exploit it if they have been denied access to a specific tool but can bind that tool's identifier through tool_ids, skill_tool_ids, or mcp_tool_ids. The vulnerable execution paths are agent and workflow tool dispatch.
What is exposed if exploitation succeeds?
The affected dispatch path can execute the denied tool and decrypt its server-side init_params. This may disclose credentials carried by that tool and allows low-privilege users to invoke functionality they were not granted.
Are deployments affected by default?
The issue affects MaxKB versions 2.0.0 through 2.9.2 where a workspace member is denied a tool through WorkspaceUserResourcePermission and the tool can still be bound through the specified identifier fields. Dedicated tool routes enforce the per-tool grant, but the agent and workflow dispatch paths do not reapply it.
What can be done if patching is not available?
No fixed version is available as of the review. Restrict or remove access to agent and workflow configurations that allow low-role members to supply tool_ids, skill_tool_ids, or mcp_tool_ids for tools they are denied, and review denied tools for credentials in init_params.