IntentKit Hid Owner-Only Wallet Tools From the Model but Not From the Executor

CVE-2026-76066, published October 15, 2026, lets public callers of IntentKit agents run owner-only tools such as wallet transfers and posting. VulnCheck rates it CVSS 4.0 8.7 High, and no fixed release exists beyond the affected 2.6.3.

A curtain hides a locked wallet from a small robot while a hand reaches it through an open service hatch
A curtain hides a locked wallet from a small robot while a hand reaches it through an open service hatch

A newly published vulnerability in IntentKit, Crestal Network’s open-source framework for autonomous AI agents, lets public callers run tools that are meant only for an agent’s owner, including a wallet transfer tool that every agent carries by default. The flaw is tracked as CVE-2026-76066 and was published to the National Vulnerability Database on October 15, 2026 at 07:50 IST, with VulnCheck as the assigning authority. VulnCheck, the assigning authority, rates it CVSS 4.0 8.7 High, with a network attack vector, low complexity, no privileges and no user interaction, and high integrity impact. NVD still lists the record as “Received”, meaning it has not yet published its own analysis or score. The record lists IntentKit through 2.6.3 as affected. No fixed version exists: 2.6.3, released June 14, 2026, is still the project’s latest GitHub release.

VulnCheck credits Noy Pearl, Michael Sromin and Ophir Dror. Lasso Security’s vulnerability database carries a detailed entry naming the files and functions involved. Lasso Security scores it CVSS 3.1 7.5 and says it knows of no public exploit.

Two layers that disagree about which tools exist

IntentKit lets operators mark each tool as public or private, with private tools meant to be reachable only by the agent’s owner. According to Lasso’s write-up, that restriction is enforced in only one place. A component called ToolBindingMiddleware narrows the list of tools advertised to the model on each request. If the caller is not the owner, the model sees only the public set.

The executor that actually runs tool calls is built differently. It constructs a LangGraph ToolNode from the full private superset: public tools, owner-only tools, and system tools such as cdp_native_transfer, create_post, update_memory and call_agent. When a tool call arrives, the executor checks it against that full registry, not against the narrowed list the model was shown. A call that names a hidden tool still runs.

The owner check itself is narrow. Lasso says the stream handler marks a session as private only for the agent owner, a matching team, or the local system user. Callers coming in through the web, API, Twitter or Telegram entrypoints with any other user ID are treated as public. Those are exactly the channels a publicly deployed agent is built to serve.

How a public caller reaches the hidden tools

VulnCheck’s description names two routes. The first is indirect prompt injection. Content the agent retrieves or receives, such as a web page, a reply or a forwarded message, supplies the exact name and arguments of a hidden tool, and the model emits the call. The second is replaying checkpoint and history data on a reused conversation thread. Lasso notes that thread IDs follow an agent_id-chat_id pattern.

Nothing stops the call once it is made. Lasso reports that no IntentKit tool carries an interrupt, human-in-the-loop step or approval gate, so a state-changing tool executes immediately. The impact list covers wallet transfers, DeFi swaps, social posts, memory writes and calls to other agents. Memory writes and agent-to-agent calls can outlast the single request that triggered them.

The wallet angle is what makes the bug more than a permissions footnote. Lasso says cdp_native_transfer is one of the system tools folded into every agent’s private set. That makes a transfer tool reachable by default rather than something an operator chose to expose.

No patch, so mitigation falls to operators

With no fixed release, exposure depends on deployment. Agents that serve public users, run as Twitter or Telegram bots, or read untrusted web or retrieved content are the configurations VulnCheck’s description puts in scope. An IntentKit agent used only by its owner over private channels does not offer an outside caller the same path.

Lasso’s suggested remediation has three parts. First, enforce tool availability at the executor, either by building the ToolNode from the same filtered set the model sees or by rejecting any call not in that turn’s advertised list. Second, add an approval or human-in-the-loop gate for state-changing tools, on by default for public or shared agents. Third, treat retrieved and inbound content strictly as data, never as instructions. Until an upstream fix lands, operators running public IntentKit agents with funded wallets can apply the same ideas themselves. That means removing or unfunding wallet tools on public agents, turning off public entrypoints they do not need, and putting a confirmation step in front of anything that moves money or posts.

The repository is MIT-licensed and has more than 6,500 GitHub stars. Its most recent push was on September 16, 2026, and Crestal Network has not published its own advisory. The bug fits a pattern seen across agent frameworks: hiding a capability from the model is not the same as denying it. The authorization decision has to sit where the tool actually runs.

Topics
  • #IntentKit
  • #CVE-2026-76066
  • #AI Agents
  • #Authorization Bypass
  • #Prompt Injection
Raj M

Author

Raj M

Contributor

AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.