Grackle: Fail-open authorization in the MCP tool layer lets scoped agents perform cross-task and cross-session mutations (IDOR)
## Summary Authorization for scoped (agent) MCP callers is enforced **inline, per tool**, and is applied inconsistently — several mutating tools silently omit the ancestry/workspace check that their siblings perform. Because the MCP server authenticates all outbound gRPC with the full server API key and the backend gRPC handlers perform **no caller-based authorization**, the MCP tool layer is the *sole* authorization boundary. A malicious or prompt-injected scoped agent can therefore perform cross-task and cross-session operations it should not be allowed to (an IDOR / privilege-boundary bypass). This advisory bundles the audit's **Systemic Pattern A** findings: **F2, F6, F7, F12** (and the duplicate F19). ## Affected versions `@grackle-ai/mcp` (with `@grackle-ai/plugin-core` / `@grackle-ai/auth`) at **0.132.1** and earlier. ## Root cause - `mcp-server.ts:111-127` (`createGrpcClients`) sets `Authorization: Bearer ${apiKey}` (the full server key) on every outbound gRPC call. - Backend handlers (`updateTask`, `deleteTask`, `resumeTask`, `killAgent`, `getTask` in `plugin-core`) take only the request message — no `AuthContext` — and act on whatever ID is passed. - Therefore scope must be enforced in each MCP tool handler. Some call `assertCallerIsAncestor` (`task_complete`, `task_start`, `session_attach`, `session_send_input`); their destructive siblings do not. New tools that forget the check **fail open**. ## F2 — task_update / task_delete / task_resume bypass ancestry (High) **Location:** `packages/mcp/src/tools/task.ts:226` (task_update), `:393` (task_delete), `:465` (task_resume). These accept an arbitrary `taskId` with only a `ROOT_TASK_ID` special-case and no `assertCallerIsAncestor`. The central dispatcher hardcodes its workspace gate to `name === "task_show"`, and these tools' Zod schemas have no `workspaceId` field (so the blanket injection is stripped). They are not in `DEFAULT_SCOPED_MCP_TOOLS` but **are** in the shipped `ORCHESTRATOR_MCP_TOOLS` / `ADMIN_MCP_TOOLS` presets. **Exploit:** a scoped agent under the orchestrator persona learns a sibling/parent/cross-workspace task ID (via `task_list`/`task_search`), then `task_delete {taskId: <victim>}` (permanently destroys another agent's or the human parent's work) or `task_update` to flip a sibling to `complete`/`failed` or rewrite its dependency DAG and budgets. ## F6 — session_kill / session_resume bypass ancestry (Medium) **Location:** `packages/mcp/src/tools/session.ts:95` (session_resume), `:178` (session_kill). Call `client.killAgent` / `client.resumeAgent` directly with no auth context, unlike `session_attach`/`session_send_input`. `session_kill` is in the orchestrator preset. **Exploit:** cross-session SIGKILL DoS against a sibling agent or the root orchestrator; foreign session resume. ## F7 — Workspaceless scoped token fails open to all workspaces (Medium) **Location:** `packages/mcp/src/mcp-server.ts:565-600`. The per-task cross-workspace check (`task_show` block) is gated on `authContext.workspaceId` being truthy. A task created without a workspace (a supported config) mints a scoped token with `pid: ""` → `workspaceId: undefined`, so the check is skipped and the injected `workspaceId` becomes `""`, which the backend treats as "all workspaces." **Exploit:** a malicious agent in a workspaceless session calls `task_list` (no args) → reads every task in every workspace, then `task_show {taskId}` cross-workspace (title/description/branch/review-notes). `schedule_show` (in the default scoped allowlist) resolves by ID with no workspace check. Read-only cross-workspace disclosure. ## F12 — Scoped-token revocation is dead code (Low) **Location:** `packages/auth/src/scoped-token.ts:23,142-149`. The consuming check is wired (`auth-middleware.ts:90-92`), but `revokeTask()` is **never called outside tests** — no task-abort/stop flow invokes it — and the backing `revokedTasks` Map is in-memory only (lost on restart). A compromised agent that exfiltrated its scoped token keeps authenticating for the full 24h TTL regardless of task lifecycle. ## Remediation - **Systemic fix:** enforce scope **centrally** in the `CallToolRequest` dispatcher (`mcp-server.ts`) via a per-tool `targetTaskIdArg` / `targetSessionIdArg` descriptor so any tool that targets a task/session **fails closed** unless the caller is an ancestor (or self). - Immediately, add `assertCallerIsAncestor` (or self-or-ancestor) to `task_update`, `task_delete`, `task_resume`, `session_kill`, `session_resume`, mirroring `task_complete`/`task_start`. - F7: do **not** fail open on empty `workspaceId` — treat a scoped non-root caller with no workspace as having access to *no* workspace; apply the `task_show` membership check whenever the caller is scoped and not `ROOT_TASK_ID`; add a per-id membership check to `schedule_show`. - F12: wire `revokeTask()` into task-abort/stop flows with SQLite-backed persistence (like channel-grant revocation), or remove the dead API and document
AI Analysis
Technical Summary
Authorization for scoped MCP callers is enforced inconsistently at the MCP tool layer, which is the sole authorization boundary since backend gRPC handlers accept requests authenticated with the full server API key but perform no caller-based authorization. Several mutating tools (task_update, task_delete, task_resume, session_kill, session_resume) omit ancestry/workspace checks, allowing scoped agents to perform cross-task and cross-session operations they should not be authorized for, constituting an IDOR and privilege boundary bypass. Workspaceless scoped tokens fail open, allowing read-only cross-workspace data access. The scoped-token revocation API is dead code, providing no effective token revocation. The root cause includes setting the full server API key on outbound gRPC calls and lack of centralized scope enforcement. The advisory recommends systemic fixes to enforce scope centrally and immediate addition of ancestry checks to vulnerable tools.
Potential Impact
Scoped agents can bypass authorization controls to perform unauthorized mutations across tasks and sessions, including deleting or updating tasks belonging to other agents or workspaces, and terminating or resuming sessions they do not own. This leads to privilege boundary bypass, potential data loss, and denial of service against sibling or parent agents. Workspaceless scoped tokens allow read-only disclosure of all tasks across all workspaces. The ineffective token revocation means compromised scoped tokens remain valid for their full lifetime, increasing risk of persistent unauthorized access.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The advisory recommends a systemic fix to enforce scope centrally in the MCP tool request dispatcher, ensuring any tool targeting a task or session fails closed unless the caller is an ancestor or self. Immediate mitigation includes adding ancestry checks (assertCallerIsAncestor) to all mutating tools lacking them (task_update, task_delete, task_resume, session_kill, session_resume). Scoped tokens without workspace association should be treated as having no workspace access, enforcing membership checks on all relevant tools. The scoped-token revocation mechanism should be integrated into task lifecycle flows with persistent storage or removed if unused. Until fixes are applied, restrict use of scoped agents and monitor for unauthorized cross-task or cross-session operations.
Grackle: Fail-open authorization in the MCP tool layer lets scoped agents perform cross-task and cross-session mutations (IDOR)
Description
## Summary Authorization for scoped (agent) MCP callers is enforced **inline, per tool**, and is applied inconsistently — several mutating tools silently omit the ancestry/workspace check that their siblings perform. Because the MCP server authenticates all outbound gRPC with the full server API key and the backend gRPC handlers perform **no caller-based authorization**, the MCP tool layer is the *sole* authorization boundary. A malicious or prompt-injected scoped agent can therefore perform cross-task and cross-session operations it should not be allowed to (an IDOR / privilege-boundary bypass). This advisory bundles the audit's **Systemic Pattern A** findings: **F2, F6, F7, F12** (and the duplicate F19). ## Affected versions `@grackle-ai/mcp` (with `@grackle-ai/plugin-core` / `@grackle-ai/auth`) at **0.132.1** and earlier. ## Root cause - `mcp-server.ts:111-127` (`createGrpcClients`) sets `Authorization: Bearer ${apiKey}` (the full server key) on every outbound gRPC call. - Backend handlers (`updateTask`, `deleteTask`, `resumeTask`, `killAgent`, `getTask` in `plugin-core`) take only the request message — no `AuthContext` — and act on whatever ID is passed. - Therefore scope must be enforced in each MCP tool handler. Some call `assertCallerIsAncestor` (`task_complete`, `task_start`, `session_attach`, `session_send_input`); their destructive siblings do not. New tools that forget the check **fail open**. ## F2 — task_update / task_delete / task_resume bypass ancestry (High) **Location:** `packages/mcp/src/tools/task.ts:226` (task_update), `:393` (task_delete), `:465` (task_resume). These accept an arbitrary `taskId` with only a `ROOT_TASK_ID` special-case and no `assertCallerIsAncestor`. The central dispatcher hardcodes its workspace gate to `name === "task_show"`, and these tools' Zod schemas have no `workspaceId` field (so the blanket injection is stripped). They are not in `DEFAULT_SCOPED_MCP_TOOLS` but **are** in the shipped `ORCHESTRATOR_MCP_TOOLS` / `ADMIN_MCP_TOOLS` presets. **Exploit:** a scoped agent under the orchestrator persona learns a sibling/parent/cross-workspace task ID (via `task_list`/`task_search`), then `task_delete {taskId: <victim>}` (permanently destroys another agent's or the human parent's work) or `task_update` to flip a sibling to `complete`/`failed` or rewrite its dependency DAG and budgets. ## F6 — session_kill / session_resume bypass ancestry (Medium) **Location:** `packages/mcp/src/tools/session.ts:95` (session_resume), `:178` (session_kill). Call `client.killAgent` / `client.resumeAgent` directly with no auth context, unlike `session_attach`/`session_send_input`. `session_kill` is in the orchestrator preset. **Exploit:** cross-session SIGKILL DoS against a sibling agent or the root orchestrator; foreign session resume. ## F7 — Workspaceless scoped token fails open to all workspaces (Medium) **Location:** `packages/mcp/src/mcp-server.ts:565-600`. The per-task cross-workspace check (`task_show` block) is gated on `authContext.workspaceId` being truthy. A task created without a workspace (a supported config) mints a scoped token with `pid: ""` → `workspaceId: undefined`, so the check is skipped and the injected `workspaceId` becomes `""`, which the backend treats as "all workspaces." **Exploit:** a malicious agent in a workspaceless session calls `task_list` (no args) → reads every task in every workspace, then `task_show {taskId}` cross-workspace (title/description/branch/review-notes). `schedule_show` (in the default scoped allowlist) resolves by ID with no workspace check. Read-only cross-workspace disclosure. ## F12 — Scoped-token revocation is dead code (Low) **Location:** `packages/auth/src/scoped-token.ts:23,142-149`. The consuming check is wired (`auth-middleware.ts:90-92`), but `revokeTask()` is **never called outside tests** — no task-abort/stop flow invokes it — and the backing `revokedTasks` Map is in-memory only (lost on restart). A compromised agent that exfiltrated its scoped token keeps authenticating for the full 24h TTL regardless of task lifecycle. ## Remediation - **Systemic fix:** enforce scope **centrally** in the `CallToolRequest` dispatcher (`mcp-server.ts`) via a per-tool `targetTaskIdArg` / `targetSessionIdArg` descriptor so any tool that targets a task/session **fails closed** unless the caller is an ancestor (or self). - Immediately, add `assertCallerIsAncestor` (or self-or-ancestor) to `task_update`, `task_delete`, `task_resume`, `session_kill`, `session_resume`, mirroring `task_complete`/`task_start`. - F7: do **not** fail open on empty `workspaceId` — treat a scoped non-root caller with no workspace as having access to *no* workspace; apply the `task_show` membership check whenever the caller is scoped and not `ROOT_TASK_ID`; add a per-id membership check to `schedule_show`. - F12: wire `revokeTask()` into task-abort/stop flows with SQLite-backed persistence (like channel-grant revocation), or remove the dead API and document
CVSS v4.0
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Authorization for scoped MCP callers is enforced inconsistently at the MCP tool layer, which is the sole authorization boundary since backend gRPC handlers accept requests authenticated with the full server API key but perform no caller-based authorization. Several mutating tools (task_update, task_delete, task_resume, session_kill, session_resume) omit ancestry/workspace checks, allowing scoped agents to perform cross-task and cross-session operations they should not be authorized for, constituting an IDOR and privilege boundary bypass. Workspaceless scoped tokens fail open, allowing read-only cross-workspace data access. The scoped-token revocation API is dead code, providing no effective token revocation. The root cause includes setting the full server API key on outbound gRPC calls and lack of centralized scope enforcement. The advisory recommends systemic fixes to enforce scope centrally and immediate addition of ancestry checks to vulnerable tools.
Potential Impact
Scoped agents can bypass authorization controls to perform unauthorized mutations across tasks and sessions, including deleting or updating tasks belonging to other agents or workspaces, and terminating or resuming sessions they do not own. This leads to privilege boundary bypass, potential data loss, and denial of service against sibling or parent agents. Workspaceless scoped tokens allow read-only disclosure of all tasks across all workspaces. The ineffective token revocation means compromised scoped tokens remain valid for their full lifetime, increasing risk of persistent unauthorized access.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The advisory recommends a systemic fix to enforce scope centrally in the MCP tool request dispatcher, ensuring any tool targeting a task or session fails closed unless the caller is an ancestor or self. Immediate mitigation includes adding ancestry checks (assertCallerIsAncestor) to all mutating tools lacking them (task_update, task_delete, task_resume, session_kill, session_resume). Scoped tokens without workspace association should be treated as having no workspace access, enforcing membership checks on all relevant tools. The scoped-token revocation mechanism should be integrated into task lifecycle flows with persistent storage or removed if unused. Until fixes are applied, restrict use of scoped agents and monitor for unauthorized cross-task or cross-session operations.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-f9ff-5x35-7gfw
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["npm"]
- Database Specific Severity
- HIGH
- Cvss Version
- 4.0
Threat ID: 6a46ecb727e9c7971943ca2e
Added to database: 07/02/2026, 22:56:55 UTC
Last enriched: 07/02/2026, 23:12:07 UTC
Last updated: 07/28/2026, 05:26:48 UTC
Views: 30
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.