- The Mess: HKUDS nanobot contains an SSRF in its
WebFetchToolthat lets an attacker make the AI agent request internal network resources, including cloud metadata services. The vulnerable URL validator simply checks whether a URL uses HTTP or HTTPS. - The Damage: A compromised agent can become a network bridge into localhost, private infrastructure and cloud metadata, potentially exposing IAM credentials and internal service data.
- The Fix: Upgrade nanobot to 0.3.0 or later and restrict the agent’s outbound network access immediately.
AI agents are supposed to fetch information from the Internet.
That is the feature.
It is also the attack surface.
CVE-2026-92576 demonstrates what happens when an AI agent can be convinced to fetch something it was never supposed to reach.
The vulnerability affects HKUDS nanobot versions before 0.3.0 and sits inside the WebFetchTool component. The flaw is a classic Server-Side Request Forgery, but the affected system is not an ordinary web application.
It is an AI agent with access to chat channels.
That changes the threat model considerably.
The current CVE record assigns the vulnerability CVSS 8.6 under CVSS 3.1 and 9.2 under CVSS 4.0. It requires no privileges and no user interaction according to the published vector.
The URL validator checks almost nothing
The vulnerable _validate_url() function does something that looks reasonable at first glance.
It checks whether the requested URL uses:
- HTTP
- HTTPS
and whether the URL contains a hostname.
Then it accepts the request.
The problem is what it doesn’t check.
It does not resolve the hostname and determine where the request will actually go.
It does not reject private RFC 1918 addresses.
It does not reject loopback addresses.
It does not reject link-local destinations.
It does not prevent access to cloud metadata infrastructure.
The official security advisory documents the vulnerable validation logic and explicitly notes that internal targets pass the check.
That creates a fundamental mismatch:
“Is this a valid URL?”
is not the same question as:
“Is this a safe destination for an AI agent to contact?”
The AI becomes the network proxy
This is where nanobot becomes interesting.
The attacker does not necessarily need direct network access to the internal service.
They need the ability to send a message to the bot through an enabled chat channel.
The advisory describes an attack path in which an attacker sends a message instructing nanobot to fetch a URL.
The agent then invokes WebFetchTool.
The tool validates the URL.
The validation succeeds.
The HTTP client makes the request from the nanobot host.
The response is then returned through the agent.
The attacker has effectively transformed:
Chat message
into:
server-side network request
That is classic SSRF.
The AI layer simply makes the attack surface much more interesting.
Internal addresses were considered valid destinations
The technical advisory demonstrates that the vulnerable validation accepts destinations including private IPv4 ranges, localhost and IPv6 loopback.
It also identifies cloud metadata services as targets.
That means the vulnerable process can potentially reach resources that were never intended to be exposed to an external user.
A normal Internet-facing web application might have a firewall separating it from sensitive infrastructure.
But the application itself often has legitimate access to:
- internal APIs
- databases
- caches
- Kubernetes services
- monitoring systems
- cloud metadata
- administrative interfaces
SSRF turns those legitimate network permissions into an attack primitive.
Cloud IAM credentials are the ugly part
Cloud metadata services deserve special attention.
Cloud instances frequently expose metadata through a link-local endpoint that is accessible from the instance itself.
Depending on the cloud platform and configuration, metadata can expose temporary credentials associated with the workload.
The nanobot advisory specifically warns that successful exploitation can expose AWS IAM role credentials, GCP service-account tokens and Azure managed-identity tokens.
That changes the potential impact from:
“attacker can query an internal HTTP service”
to:
“attacker may obtain credentials belonging to the cloud workload.”
Those credentials can then potentially be used against cloud APIs according to whatever permissions the workload has.
The vulnerability therefore crosses a security boundary.
The attacker starts outside the AI agent.
The request originates inside the server’s network context.
The response can contain credentials or internal data.
Redirects make the validator even weaker
There is another problem in the implementation.
The HTTP client follows redirects.
The ZDI advisory documents that httpx.AsyncClient is configured with follow_redirects=True.
That means a URL that initially appears external can redirect the agent toward an internal destination.
Conceptually:
External URL
↓
HTTP redirect
↓
Internal destination
↓
Response returned to the agent
A URL allow-check performed only before the first request is therefore insufficient.
SSRF defenses have to account for the final destination, not merely the first hostname supplied by the attacker.
This is not prompt injection
It is tempting to classify every AI-agent vulnerability as prompt injection.
That would be wrong here.
The underlying security defect is CWE-918: Server-Side Request Forgery.
The attacker uses the AI agent’s natural-language interface to reach the vulnerable network-fetching capability, but the root cause is the unsafe URL validation in WebFetchTool.
That distinction matters.
The LLM does not need to be “jailbroken” for the vulnerability to exist.
The dangerous capability is already available.
The security boundary around that capability is broken.
Chat integrations expand the attack surface
Nanobot is designed to interact through multiple chat platforms.
The ZDI advisory specifically discusses channels including Telegram, Discord and Slack.
It also notes that the default configuration can allow messages from senders unless an allow_from list is configured.
That creates an unusual architecture:
External user
↓
Chat platform
↓
AI agent
↓
Tool invocation
↓
HTTP client
↓
Internal network
Traditional SSRF usually starts with a vulnerable HTTP parameter.
Here, the parameter can effectively be a conversational instruction.
That makes access control around the agent itself extremely important.
The attacker does not need an account on the internal service
That is one of the main reasons the CVSS vector contains:
PR:N
The attacker does not need credentials for the internal target.
The request is made by nanobot.
The internal service sees a request originating from the trusted network position of the agent.
If that internal service trusts the source network, the SSRF can cross another security boundary.
This is a common reason SSRF remains dangerous even when internal applications have strong authentication.
Network location itself often carries trust.
The vulnerability was found in a real AI-agent framework
This is not an academic demonstration against a fictional agent.
The affected package is nanobot-ai, and the official advisory lists versions below 0.3.0 as affected and 0.3.0 as patched.
The tested version was nanobot 0.1.4.
The vulnerability was reported through Trend Micro’s Zero Day Initiative, with the advisory credited to Peter Girnus and Project AESIR of TrendAI ZDI.
That makes the issue particularly relevant to anyone experimenting with self-hosted AI agents.
The security model of an agent is not only about what the model can say.
It is about what the agent’s tools can touch.
The fix is not just “upgrade”
Upgrading nanobot to 0.3.0 or later is the primary remediation.
But defenders should also reduce the blast radius.
The agent should not have unrestricted outbound network access.
A sensible deployment should restrict:
- access to cloud metadata services
- localhost services
- RFC 1918 networks
- Kubernetes control-plane endpoints
- internal administrative APIs
- databases
- Redis and similar infrastructure
- management interfaces
The agent should also use an explicit allowlist for external destinations where practical.
If the AI only needs to fetch documentation and public websites, it has no business being able to reach the entire corporate network.
Cloud workloads need another layer
If nanobot runs inside AWS, Azure or GCP, metadata protection should be enabled independently of the application.
The principle is simple:
Do not trust the application to protect the metadata endpoint.
The application already has a vulnerability.
Cloud-level controls should make it harder for an SSRF bug to turn into credential theft.
Network egress controls, metadata-service protections and least-privilege IAM roles can significantly reduce the consequences.
The goal is not merely to prevent SSRF.
The goal is to prevent:
SSRF → credentials → cloud takeover
from becoming a single straight line.
No active exploitation confirmed
CVE-2026-92576 is extremely fresh.
The current vulnerability records do not show it in CISA KEV, and available tracking does not show a public exploit or confirmed active exploitation.
That should be stated clearly.
This is a newly disclosed critical/high-severity AI-agent SSRF with a public technical advisory and proof-of-concept material, not a confirmed in-the-wild zero-day.
The distinction matters.
The attack surface, however, is already public.
Bugstoday’s take
This is what happens when an AI agent gets network privileges before someone properly defines where those privileges are allowed to go.
Nanobot can fetch URLs.
Fine.
But “URL” cannot mean:
anything reachable from the server.
An AI agent running inside a cloud environment should be treated as an application with potentially dangerous automation privileges.
Give it unrestricted HTTP access and an attacker does not need to hack the agent directly.
They can simply tell it where to look.
The nasty part of CVE-2026-92576 is not the SSRF itself.
It is the combination:
AI agent + chat interface + server-side fetch + internal network access + cloud metadata.
That is a very short path from a harmless-looking message to infrastructure secrets.
Upgrade nanobot. Restrict egress. Block metadata access. Give AI agents the minimum network privileges they actually need.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- HKUDS nanobot security advisory — GHSA-vc5v-6vwm-wf9m — technical details, affected versions, attack path and remediation.
- CVE-2026-92576 record — CVE metadata and severity.
- HKUDS nanobot repository — project source and release information.
