MaxKB EUVD-2026-84157

Requires an authenticated MaxKB workspace account at the lowest role that has been explicitly DENIED a given tool through WorkspaceUserResourcePermission; the attacker must know or enumerate the identifier of the denied tool. Exploitation occurs specifically through the agent or workflow dispatch path (binding the id via tool_ids, skill_tool_ids, or mcp_tool_ids) - the dedicated tool routes correctly enforce the grant and are NOT the vector. Impact is meaningful only when the denied tool carries sensitive init_params/credentials. Limiting factors: valid low-privilege authentication is mandatory (not remote-unauthenticated), it is confined to versions 2.0.0 through 2.9.2, and no patch exists so mitigation must be operational (restrict tool credential exposure / workspace membership).

This is a genuine but access-gated privilege/authorization flaw, not a top-priority internet-wide crisis. The vendor CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N = 5.4) tells the real story: an authenticated, low-privilege caller is required (PR:L), so this is exploitable only by someone already inside a MaxKB workspace. No EPSS score, CISA KEV entry, or public POC is present in the supplied data, so the exploitation status is 'no public exploit identified at time of analysis' - do not treat this as actively exploited. The stated impacts (C:L/I:L) understate the credential-disclosure angle: because denied-tool execution decrypts server-side init_params and returns credentials to the caller, the confidentiality impact against those secrets is arguably C:H (those credentials can then be reused against upstream services), so 5.4 is a floor rather than a ceiling. Aggravating factor: NO fixed version exists as of this review, so defenders cannot patch and must rely on operational controls. Net: real priority for organizations running multi-tenant MaxKB workspaces with sensitive tool credentials, low priority for single-admin deployments.

A lowest-role member of a shared MaxKB workspace is explicitly denied access to a privileged tool (e.g., one holding an API key) by WorkspaceUserResourcePermission. The attacker crafts an agent or workflow definition that references the forbidden tool's identifier via tool_ids/skill_tool_ids/mcp_tool_ids and dispatches it; the dispatch path never re-checks the per-tool grant, executes the tool, decrypts its init_params, and hands the embedded credentials back to the caller. No public exploit code is identified, but the technique requires only ordinary API access and knowledge of the target tool id.