MaxKB EUVD-2026-84154

Requires an authenticated normal (non-privileged) user account within the same MaxKB workspace as the victim (PR:L) plus prior knowledge of the victim's active MCP tool_id - the tool-detail route fails to apply the per-resource authorization that the list route enforces. Secondary abuse (using the foreign MCP configuration) requires the attacker to have permission to create or edit an attacker-owned workflow and run workflow debug. Limiting factors: exploitation is confined to members of the same workspace, needs a valid/known tool_id, and yields only disclosure of MCP config/headers and unauthorized use of that configuration - no direct integrity or availability impact. Affects MaxKB 2.10.2-lts and earlier; no fixed version available at time of review.

This is a genuine but modestly-scoped authorization flaw (CWE-862 missing object-level authorization / IDOR), not a true 'Authentication Bypass' as tagged. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N, base 5.0) is internally consistent with the description: a network-reachable, low-complexity request from an already-authenticated workspace member, no user interaction, scope change (S:C, because the attacker reads another user's resource across a privilege boundary), and low confidentiality impact (leak of Tool.code / MCP server config and headers) with no integrity or availability impact. No EPSS score, KEV listing, or public POC is provided, so there is no signal of active or automated exploitation - this is a targeted, insider-style abuse requiring an authenticated same-workspace account plus prior knowledge of a victim's active MCP tool_id, not a mass-exploitable RCE. Realistic priority is MEDIUM-LOW: the real-world risk is bounded by the authentication requirement, the niche self-hosted deployment footprint, and the fact that impact is confined to disclosure/misuse of MCP configuration rather than direct code execution. Key limiting factor to flag: no fixed version is available as of this review, so mitigation is currently operational (access control / trust in workspace members) rather than a patch.

An authenticated normal member of a MaxKB workspace learns or enumerates another user's active MCP tool_id and requests it via the tool-detail route, which - unlike the list route - skips per-resource authorization and returns Tool.code containing the owner's MCP server configuration and headers. The attacker then embeds that foreign mcp_tool_id in an attacker-owned workflow's mcp-node and runs workflow debug, causing MaxKB to execute against the victim's MCP configuration without any permission check. No public exploit code is identified at time of analysis; exploitation is straightforward given valid workspace credentials and a known tool_id.