IntentKit through 2.6.3: the executor runs owner-only tools, wallet transfer included, for any caller via prompt injection (CVE-2026-76066, 8.7); no fix

View raw markdownEdit on GitHub ↗

TL;DR

IntentKit, an open-source autonomous-agent framework whose agents carry crypto wallets and social-media tools, checks a tool call against the agent's full tool registry instead of the per-request list its ToolBindingMiddleware narrowed for the caller, so an owner-only tool runs when a non-owner request names it (CVE-2026-76066, VulnCheck CNA, CVSS 4.0 8.7, published 2026-10-15). Unauthenticated or public callers in the WEB, API, Twitter or Telegram entrypoints can name a de-advertised tool, including the always-present wallet transfer tool, through indirect prompt injection or by replaying checkpoint and history data on a reused thread, and no tool has a human approval gate. Affected through 2.6.3, which is the newest tag on the repository; no fix, no vendor response and no exploit on record as of 2026-10-15.

What happened

VulnCheck published the record on 2026-10-15 and credits Noy Pearl, Michael Sromin and Ophir Dror; the record's other reference is Lasso Security's vulnerability-database page, which names no reporter and no fix. The CNA record lists crestalnetwork intentkit with versions 0 through 2.6.3 affected (inclusive), CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N) and CVSS 3.1 7.5, CWE-862.

The mechanism, as both pages describe it: tool visibility is enforced only in the list shown to the model. The executor is built from the full private tool set, so when a request names an owner-only tool the executor runs it, whether the model chose it after reading injected text or the name arrived in replayed checkpoint or history data on a thread that is reused across callers. Lasso lists intentkit/core/executor.py, intentkit/core/middleware.py, intentkit/core/engine/stream.py and intentkit/tools/base.py as the files involved and names wallet transfer, posting, memory write and call-agent as the state-changing tools reachable this way. The repository's releases page shows v2.6.3 as the latest tag, so the record's upper bound is the current release, and the repository's security tab was not referenced by either page.

Lasso's remediation suggestions, which the CNA record repeats, are to enforce tool availability at the executor rather than at the prompt, and to add a human approval step to any tool that moves money, posts publicly or writes memory. Neither page cites a pull request, commit or maintainer reply. This is the same shape as the Continue CLI and sandboxed.sh records in the 2026-10-13 batch: a static allow or deny decision at one layer that the executing layer never sees.

Am I affected?

IntentKit is run from a checkout of crestalnetwork/intentkit, not from a registry: pip index versions intentkit returns nothing on 2026-10-15, and the npm package intentkit@5.0.0 is a different project (mosoahmed/intentkit), not the one the record means.

git -C /path/to/intentkit describe --tags 2>/dev/null   # v2.6.3 or earlier = affected
grep -rn 'ToolBindingMiddleware\|owner_only\|wallet_transfer' --include='*.py' . 2>/dev/null | head
# entrypoints that take untrusted input
grep -rn 'TWITTER\|TELEGRAM\|entrypoint' --include='*.py' intentkit 2>/dev/null | head

Affected if any IntentKit agent at 2.6.3 or earlier accepts messages from the public (web chat, API, Twitter, Telegram) and has owner-only tools configured. The wallet transfer tool is always present per the CNA record.

If you are affected

There is no upgrade. Until a fix exists, take public entrypoints off agents that hold wallets or posting credentials, move funds out of agent wallets, add an approval step outside the model for state-changing tools, and do not reuse threads across callers. If an agent's wallet or social account was used without the owner's instruction, treat its keys as compromised and follow if-your-local-ai-agent-was-exploited.md and rotating-cloud-credentials.md.

Prevention

  • Authorize tool calls where they execute, not where they are listed; a prompt-side filter is advice to the model, not a control.
  • Keep money-moving and posting tools behind an approval that the model cannot satisfy. See agent-sandboxing.md.

Sources