IntentKit flaw lets outsiders trigger wallet transfers

A flaw in IntentKit, an agent framework, allows unauthenticated callers to run owner-only tools such as wallet transfers, according to an entry published in the US National Vulnerability Database on 15 October 2026. The issue is tracked as CVE-2026-76066 and affects IntentKit through version 2.6.3.

According to the NVD record, the problem is an authorisation bypass in the way IntentKit decides which tools an agent is allowed to call. The framework includes a component called ToolBindingMiddleware, which narrows the list of tools advertised to the model on a per-request basis. In other words, a request from an anonymous web user is supposed to see a smaller menu of capabilities than a request from the agent's owner. But the executor, the part that actually runs the tool calls, validates each call against the full tool registry instead of that narrowed list. Anything registered anywhere in the system is therefore accepted, whether or not it was offered for that request.

The result, the NVD entry says, is that owner-only state-changing tools can run with no human-in-the-loop step and no approval gate. The record names wallet transfer, posting, memory-write and call-agent as examples. Memory-write changes an agent's stored state, and call-agent invokes another agent, so a successful call can persist beyond the single request that triggered it.

Two exploitation routes are described. In the first, an attacker supplies the exact name and arguments of a tool that was deliberately left out of the advertised list, delivered through indirect prompt injection. That means hiding instructions in content the agent reads, such as a web page or an incoming message, rather than typing them into a prompt directly. In the second, an attacker replays checkpoint and history data on a reused conversation thread, so that a previously recorded call is executed again under weaker authorisation.

The NVD record states that an unauthenticated or public caller can carry this out in WEB, API, TWITTER and TELEGRAM contexts. Those are the surfaces where an IntentKit agent accepts input from people who are not its owner, which is what makes the gap between the advertised and the enforced tool list exploitable rather than theoretical.

The pattern is a familiar one in agent frameworks. The list of tools shown to the model is a prompt-level hint, not a security boundary. If the executor does not apply the same restriction when the call comes back, the model's input becomes the only thing standing between an untrusted message and a funds transfer. Prompt injection then stops being a content problem and becomes an access control problem.

The NVD entry lists advisories from Lasso Security and VulnCheck as references. The record gives no fixed version and no mitigation guidance beyond the description of the flaw, and does not say whether the vulnerability has been exploited against live deployments. IntentKit has not published a statement in the material referenced by the NVD entry. Operators running IntentKit at or below 2.6.3 with public-facing channels enabled are the stated exposure.