NewApp Monitoring is liveSign up free
AgentbeamBeta
AI agent vulnerability · Other MCP servers and tools

GHSA-f9ff-5x35-7gfw: Grackle: Fail-open authorization in the MCP tool layer lets scoped agents perform cross-task and cross-session mutations (IDOR)

highCVSS 4.0 8.7

Grackle's MCP tool layer (`@grackle-ai/mcp`, `@grackle-ai/plugin-core`, `@grackle-ai/auth`, 0.132.1 and earlier) checks scope per tool, and several mutating tools skip the check. A malicious or prompt-injected scoped agent can delete, update or kill tasks and sessions that belong to others. No patched version is listed yet.

Published Jul 2, 2026 · Analysis Oct 25, 2026

What an attacker can do

The MCP server sends every outbound gRPC call with the full server API key, and the backend handlers (updateTask, deleteTask, resumeTask, killAgent, getTask) do no caller-based authorization. So each MCP tool handler is the only boundary. task_complete, task_start, session_attach and session_send_input call assertCallerIsAncestor. Their destructive siblings do not, and a new tool that forgets the check fails open.

The advisory bundles four findings:

  • task_update, task_delete and task_resume accept any taskId. An agent that learns another task's ID through task_list or task_search can delete a sibling's or the human parent's work, or flip tasks to complete or failed and rewrite the dependency graph. Rated High.
  • session_kill and session_resume call the backend with no auth context, enabling cross-session kills of sibling agents or the root orchestrator. Rated Medium.
  • A task created without a workspace mints a scoped token with an empty workspace, which the backend treats as all workspaces. The agent can list and read every task, and use schedule_show, across workspaces. Rated Medium, read-only.
  • revokeTask() is never called outside tests, and revocations are in memory. A stolen scoped token works for its full 24-hour lifetime. Rated Low.

The attacker is an agent running with a scoped token, which a prompt injection can hijack. The mutating tools sit in the shipped orchestrator and admin presets.

Who is affected

@grackle-ai/mcp, @grackle-ai/plugin-core and @grackle-ai/auth at 0.132.1 and earlier. The task_update, task_delete, task_resume, session_kill and session_resume findings matter where agents use the orchestrator or admin tool presets. The cross-workspace read applies to workspaceless tasks.

npm ls @grackle-ai/mcp @grackle-ai/plugin-core @grackle-ai/auth

Any result at or below 0.132.1 is affected.

@grackle-ai/mcp

Ecosystem
npm
Affected
<= 0.132.1
Fixed in
No patched version yet
Check
npm ls @grackle-ai/mcp

@grackle-ai/plugin-core

Ecosystem
npm
Affected
<= 0.132.1
Fixed in
No patched version yet
Check
npm ls @grackle-ai/plugin-core

@grackle-ai/auth

Ecosystem
npm
Affected
<= 0.132.1
Fixed in
No patched version yet
Check
npm ls @grackle-ai/auth

How to fix it

There is no patched version yet. The advisory lists all three packages as unpatched through 0.132.1, and names no fix commit or release. Watch the project's advisory page for a release.

The advisory's recommended remediation, for maintainers: add assertCallerIsAncestor or a self-or-ancestor check to the five mutating tools, enforce scope centrally in the CallToolRequest dispatcher so tools fail closed, stop treating an empty workspaceId as all workspaces, and wire revokeTask() into task abort and stop flows.

One inference from the advisory, not a documented workaround: the mutating tools are in the orchestrator and admin presets, so do not give those presets to scoped agents that handle untrusted input. Always give workspaces to tasks.

How to tell if you were hit

Review Grackle logs for task_delete, task_update, task_resume, session_kill and session_resume calls where the target task or session is not the caller or a descendant of it. Look for tasks that disappeared, flipped to complete or failed without cause, or sessions killed unexpectedly. In workspaceless sessions, look for task_list calls with no arguments and task_show calls on IDs from other workspaces. Beam records agent MCP tool calls, so it can show which tools an agent called and with what arguments.

Original advisory

From the GitHub Advisory Database (CC BY 4.0).

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 the 24h window.
  • Add regression tests mirroring the existing task_complete ancestor tests for each mutator.

CWEs

CWE-862 (Missing Authorization), CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR), CWE-613 (Insufficient Session Expiration).

Questions

Is there a fixed version of Grackle?

Not as of this advisory. Patched versions are listed as none for all three affected packages, which are affected through 0.132.1.

How would an attacker get a scoped agent?

The advisory describes a malicious or prompt-injected scoped agent. A poisoned input that steers the agent's tool calls is enough, since the tools do not check ancestry.

Can it leak data across workspaces?

Yes, read-only. A task created without a workspace gets a token that the backend treats as all workspaces, so task_list, task_show and schedule_show can reach other workspaces.

Does token revocation help?

Not yet. revokeTask() is never called outside tests and its state is in memory only, so a stolen scoped token stays valid for 24 hours.

References

How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. The analysis is written by an AI model from the sources listed above and checked by automated rules before it is published. Check versions against the vendor's advisory before you act. Methodology

More Other MCP servers and tools vulnerabilities

All Other MCP servers and tools entries