nanobot CVE-2026-19244

Exploitation requires that the operator has explicitly configured enabledTools for an MCP server connection with a non-wildcard value - either an empty list [] (deny-all) or a specific named list of tool names. Deployments using the default enabledTools: ['*'] are not affected, because resources and prompts are already intended to be fully registered and no restriction is in place to bypass. Additionally, the connected MCP server must expose at least one resource or prompt (in addition to tools) for the unintended registrations to occur. Per the CVSS 4.0 PR:H metric, exploitation further requires high-privilege access - either to the nanobot deployment to query registered capabilities, or to operate or influence a connected MCP server. Limiting factors: the impact is confined to capability scope exposure (Low C/I/A); there is no remote code execution, credential theft, or lateral movement directly enabled by this flaw; and the vulnerable code path is only reached during MCP server connection initialization, not on every request.

The CVSS 4.0 score of 5.1 (AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P) characterizes this as medium severity with a public exploit. PR:H is the critical limiting factor: exploitation requires an attacker with high-privilege access - either operator-level control over the nanobot configuration or the ability to operate or influence a connected MCP server. The VC/VI/VA impacts are all Low, consistent with a scope-bypass that exposes restricted capabilities rather than enabling full system compromise. No EPSS score was provided in the input data, so probabilistic exploitation likelihood cannot be quantified. The absence of a CISA KEV listing further suggests this is not being broadly exploited opportunistically. Real-world risk is tightly scoped: deployments using the default enabledTools: ['*'] configuration are entirely unaffected, as the fix only changes behavior when a restrictive allowlist is set. The vulnerability is meaningful only in environments that actively use fine-grained enabledTools restrictions - a deliberate operator hardening step - meaning the population of affected-in-practice deployments is a subset of already security-conscious operators. The public POC increases urgency for that subset.

An operator deploys nanobot with a connected external MCP server and configures enabledTools: ['search_tool'], expecting only the search_tool capability to be available to the agent. The MCP server also advertises a resource named secret_data and a prompt named admin_prompt that the operator intended to block. Due to the vulnerability, both are registered into the tool registry unconditionally. A user or agent session with access to the nanobot instance can then invoke secret_data or admin_prompt, bypassing the operator's intended access boundary. A public proof-of-concept demonstrating this bypass is available at https://gist.github.com/YLChen-007/3de5f50d167a878f7530f57ed018d508.