npm package report

Is @grackle-ai/auth safe?

1 known vulnerability, worst severity HIGH.

// reach

0 direct dependencies

none carry a known advisory

    0 packages depend on it

    an advisory here reaches each of them

      Create a free accountfor every dependency path, dependent and what to upgrade
      // ai model usage

      Tracked for PyPI packages. HuggingFace models declare Python dependencies, so npm packages are not covered.

      cvss
      0.0
      high

      severity band, no base score published

      epss
      not scored

      chance of exploitation in 30 days

      xyz score
      not scored

      CyberXYZ composite out of 10

      fig. 01 — GHSA-f9ff-5x35-7gfw, the advisory selected below

      // 1 advisories

      GHSA-f9ff-5x35-7gfw

      HIGH
      // 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 (taskcomplete, taskstart, sessionattach, sessionsendinput); their destructive siblings do not. New tools that forget the check fail open.
      // f2 — taskupdate / taskdelete / taskresume bypass ancestry (high)

      Location: packages/mcp/src/tools/task.ts:226 (taskupdate), :393 (taskdelete), :465 (taskresume).

      These accept an arbitrary taskId with only a ROOTTASKID special-case and no assertCallerIsAncestor. The central dispatcher hardcodes its workspace gate to name === "taskshow", and these tools' Zod schemas have no workspaceId field (so the blanket injection is stripped). They are not in DEFAULTSCOPEDMCPTOOLS but are in the shipped ORCHESTRATORMCPTOOLS / ADMINMCPTOOLS presets.

      Exploit: a scoped agent under the orchestrator persona learns a sibling/parent/cross-workspace task ID (via tasklist/tasksearch), then taskdelete {taskId: } (permanently destroys another agent's or the human parent's work) or taskupdate to flip a sibling to complete/failed or rewrite its dependency DAG and budgets.

      // f6 — sessionkill / sessionresume bypass ancestry (medium)

      Location: packages/mcp/src/tools/session.ts:95 (sessionresume), :178 (sessionkill).

      Call client.killAgent / client.resumeAgent directly with no auth context, unlike sessionattach/sessionsendinput. sessionkill 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 (taskshow 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 tasklist (no args) → reads every task in every workspace, then taskshow {taskId} cross-workspace (title/description/branch/review-notes). scheduleshow (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 taskupdate, taskdelete, taskresume, sessionkill, sessionresume, mirroring taskcomplete/taskstart.
      • 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 taskshow membership check whenever the caller is scoped and not ROOTTASKID; add a per-id membership check to scheduleshow.
      • 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 taskcomplete ancestor tests for each mutator.
      // cwes

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

      Checked 2026-09-26 at 01:05 UTC. The most recent advisory here was published 2026-07-02. Updated continuously from NVD, GHSA, OSV and CNA feeds.

      Think a verdict here is wrong? Tell us — we respond within 2 business days.