How severe is GHSA-f9ff-5x35-7gfw?

No CVSS score has been assigned to GHSA-f9ff-5x35-7gfw yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-f9ff-5x35-7gfw?

GHSA-f9ff-5x35-7gfw affects the following packages: @grackle-ai/mcp (npm), @grackle-ai/plugin-core (npm), @grackle-ai/auth (npm). Ecosystems affected: npm.

How do I fix GHSA-f9ff-5x35-7gfw?

No patched version of @grackle-ai/mcp has shipped for GHSA-f9ff-5x35-7gfw yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

How do I detect GHSA-f9ff-5x35-7gfw in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @grackle-ai/mcp. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-f9ff-5x35-7gfw if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-f9ff-5x35-7gfw?

O3 pinpoints whether GHSA-f9ff-5x35-7gfw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-f9ff-5x35-7gfw actively exploited in the wild?

No public exploit code has been indexed for GHSA-f9ff-5x35-7gfw yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-f9ff-5x35-7gfw published, and has it been updated?

GHSA-f9ff-5x35-7gfw was published on July 2, 2026 and was last updated on July 2, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-f9ff-5x35-7gfw

Grackle: Fail-open authorization in the MCP tool layer lets scoped agents perform cross-task and cross-session mutations (IDOR)

Published

Jul 2, 2026

Updated

Jul 2, 2026

Affected

3 pkgs

Patched

None yet

Exploits

None indexed

Blast Radius

3 pkgs affected

Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.

@grackle-ai/mcpnpm

299downloads / week

@grackle-ai/plugin-corenpm

334downloads / week

@grackle-ai/authnpm

211downloads / week

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 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).

Affected Packages

3 total

Ecosystem	Package	Vulnerable range	Fix
📦npm	`@grackle-ai/mcp`	all versions	No fix
📦npm	`@grackle-ai/plugin-core`	all versions	No fix
📦npm	`@grackle-ai/auth`	all versions	No fix

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @grackle-ai/mcp. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of @grackle-ai/mcp has shipped for GHSA-f9ff-5x35-7gfw yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-f9ff-5x35-7gfw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-f9ff-5x35-7gfw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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 bypa

O3 Security · Impact-Aware SCA

Is GHSA-f9ff-5x35-7gfw in your dependencies?

O3 detects GHSA-f9ff-5x35-7gfw across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works