Skip to content
PERMISSION/PROTOCOL
Back to incident tracker

2026-09-02

HighPrimary

MaxKB Agent Workflows Let Denied Users Execute Restricted Tools and Receive Their Decrypted Credentials

Analysis of CVE-2026-77516, where MaxKB agent and workflow dispatch bypassed per-tool authorization and exposed restricted tool credentials.

MaxKBGovernance bypassMissing authorization in agent and workflow tool dispatchMaxKB community-edition workspaces, agent applications, workflow dispatch, tool libraries, skills, and MCP tool bindings

What happened

In controlled testing, a low-privilege member bound a denied tool to a workflow, caused the agent dispatch path to execute it, and received the tool's decrypted server-side secret in the workflow result.

Why it matters

Demonstrated execution of tools the caller was explicitly denied and disclosure of their stored credentials; tools with privileged write behavior could also perform unauthorized mutations under the application identity.

Missing authorization check

The same principal-and-tool authorization decision at every dispatch path, including agent applications, workflows, skills, and MCP bindings, before credentials are decrypted or tool code executes.

Would PP block it?

If MaxKB delegates tool execution to an external fail-closed gate, the workflow must present authority for the same member and restricted tool before credentials are released or code runs. A missing or denied grant produces no redeemable receipt, regardless of which application path requested the tool.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-09-02

    GitHub publishes GHSA-383v-fx78-pphm with the authorization-bypass proof of concept and affected range.

  2. 2026-09-21

    The CVE Program publishes CVE-2026-77516 for MaxKB 2.0.0 through 2.9.2.

Technical breakdown

  • MaxKB's dedicated tool Debug, update, export, and delete routes checked WorkspaceUserResourcePermission and denied the low-privilege member.
  • Agent and workflow serializers accepted tool_ids, skill_tool_ids, and mcp_tool_ids without validating those identifiers against the member's per-tool grants.
  • The dispatch path checked workspace membership but did not reapply the default-deny per-tool authorization decision.
  • Tool execution decrypted server-side init_params under the application identity; the proof of concept returned the restricted tool's sentinel API key through the workflow API and tool record.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Governance bypass. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Agent and workflow dispatch before tool credential decryption and tool execution
Still needs
Permission Protocol does not patch MaxKB's vulnerable serializers or dispatch code, limit what a legitimately authorized tool can do, or replace least-privilege credential design.
Receipt required for
Executing the named tool as the requesting workspace member with the exact operation, resource scope, and bounded credential authority

A Tool-Call Gate can require a valid receipt bound to the requesting principal, exact tool, resource, and action before dispatch, so routing through a workflow cannot bypass the denied decision.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop