Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

GHSA-647h-p824-99w7 — @grackle-ai/mcp

GHSA-647h-p824-99w7 is a security vulnerability in @grackle-ai/mcp. A fix is available for @grackle-ai/mcp — see the affected versions and patch details below.

@grackle-ai/mcp has a workspace authorization bypass in its knowledge_search MCP tool

Published
Mar 25, 2026
Updated
Mar 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Mar 25, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

1other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@grackle-ai/mcpnpm
287downloads / week

Description

Impact

The knowledge_search and knowledge_get_node MCP tools are included in SCOPED_TOOLS (visible to scoped agents) but their handlers do not receive authContext and do not enforce workspace scoping. A scoped agent in Workspace A can supply an arbitrary workspaceId parameter to search or retrieve knowledge graph nodes from Workspace B, bypassing workspace isolation boundaries.

This is a cross-workspace data leakage vulnerability affecting any deployment where multiple workspaces contain sensitive knowledge graph data and scoped agents are used.

Affected code:

  • packages/mcp/src/tools/knowledge.ts:146-169 (knowledge_search handler)
  • packages/mcp/src/tools/knowledge.ts:244-283 (knowledge_get_node handler)
  • packages/mcp/src/tool-scoping.ts:11 (both tools listed in SCOPED_TOOLS)

Contrast with correct implementation: knowledge_create_node (same file, lines 334-357) properly receives authContext and overrides the user-supplied workspaceId for scoped callers.

Design Note

Cross-workspace knowledge sharing is a legitimate future feature — agents working across different repos may need to collaborate and share knowledge. However, this access should be opt-in with explicit grants, not an implicit bypass. The immediate fix locks scoped agents to their own workspace. A future design could introduce:

  • Workspace-level "share knowledge with" settings
  • A cross_workspace scope on scoped tokens
  • Explicit workspaceIds (plural) in the auth context

Patches

Fix: Add authContext parameter to knowledge_search and knowledge_get_node handlers and enforce workspace scoping, matching the pattern in knowledge_create_node:

const resolvedWorkspaceId =
  authContext?.type === "scoped"
    ? authContext.workspaceId ?? ""
    : workspaceId ?? "";

When cross-workspace collaboration is designed, this check can be relaxed intentionally with proper access controls.

Workarounds

Do not use scoped agent tokens in multi-workspace deployments until patched. Alternatively, remove knowledge_search and knowledge_get_node from the SCOPED_TOOLS set in tool-scoping.ts.

References

  • CWE-284: Improper Access Control
  • File: packages/mcp/src/tools/knowledge.ts
  • File: packages/mcp/src/tool-scoping.ts

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@grackle-ai/mcpall versions0.70.2npm install @grackle-ai/mcp@0.70.2

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @grackle-ai/mcp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @grackle-ai/mcp to 0.70.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-647h-p824-99w7 is resolved across your whole dependency graph.

  3. Workarounds

    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.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-647h-p824-99w7 can be triaged on real exposure rather than presence alone.

Tailored to GHSA-647h-p824-99w7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Impact The `knowledge_search` and `knowledge_get_node` MCP tools are included in `SCOPED_TOOLS` (visible to scoped agents) but their handlers do not receive `authContext` and do not enforce workspace scoping. A scoped agent in Workspace A can supply an arbitrary `workspaceId` parameter to search or retrieve knowledge graph nodes from Workspace B, bypassing workspace isolation boundaries. This is a **cross-workspace data leakage** vulnerability affecting any deployment where multiple workspaces contain sensitive knowledge graph data and scoped agents are used. **Affected code:** - `packa
O3 Security · Impact-Aware SCA

Is GHSA-647h-p824-99w7 in your dependencies?

O3 Security finds GHSA-647h-p824-99w7 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

Scan my dependencies How O3 SCA works
GHSA-647h-p824-99w7: @grackle-ai/mcp | O3 Security