Every AI server wants to fetch a URL: three 2026 SSRFs into cloud metadata

This is a piece about a class, not a single product. The AI and agent boom shipped a huge amount of new server-side code whose whole job is to fetch something a user pointed at: an image URL for a multimodal model, a link for a retrieval pipeline, a page for a crawler, an endpoint for a Model Context Protocol connector. Each fetch runs from inside your network with your instance's IAM role attached, and every cloud instance answers a request to 169.254.169.254 with credentials for that role. The only thing between an attacker-supplied URL and those credentials is whether the fetching code refuses to follow links into link-local and internal ranges. In 2026 a lot of it did not. Verifiable security.

Three fetches, three ways to forget the metadata endpoint

LMDeploy (CVE-2026-33626, fixed in 0.12.3, scored 7.5). LMDeploy serves vision-language models, so it turns an image reference into pixels. Its load_image() helper in lmdeploy/vl/utils.py fetched arbitrary URLs with no validation of the destination address. A vision request is supposed to carry a picture; instead it could carry http://169.254.169.254/latest/meta-data/iam/security-credentials/, the server fetched it, and the response channel returned the cloud IAM role credentials at that path. The public record is blunt: reporting indicates the flaw was exploited within roughly thirteen hours of disclosure. A loader that loads any URL is a credential exfiltration primitive the moment it runs on a cloud instance.

mcp-atlassian (CVE-2026-27826, fixed in 0.17.0, scored 8.2). This is a Model Context Protocol server bridging an AI agent to Atlassian products. The defect let an unauthenticated caller supply two custom HTTP headers that steered an outbound request to any URL of the caller's choosing, including the metadata endpoint. The sharp edge is the pre-authentication reachability: a connector meant to talk to a known SaaS backend became a general-purpose request proxy pointed wherever the attacker aimed, no credentials required.

Crawl4AI (CVE-2026-53755, fixed in 0.8.9, scored 8.6). Crawl4AI is a crawler built for feeding LLM pipelines, and it actually had an SSRF allow-and-deny check, applied to the wrong field. It validated the crawl target URL, the obvious attacker input, but not the proxy address in browser_config.proxy_config.server. So the crawl URL could look perfectly clean while the browser was routed through an internal address the check never inspected. Compounding it, Crawl4AI's Docker deployment exposes its API unauthenticated by default, so on a default install nobody was at the door at all.

Line those three up and the through-line is sharp. None is an exotic bug. Each is an SSRF defense that forgot the metadata endpoint entirely (LMDeploy), trusted an unauthenticated caller to name its own destination (mcp-atlassian), or validated one field while leaving the transport open (Crawl4AI). The metadata endpoint is the target every time: it is the one address on the cloud network that hands credentials to anyone who can reach it from the instance, and a server-side fetcher always can.

The metadata endpoint answers any request that reaches it from the instance. A fetcher that does not deny link-local and internal ranges turns that into credential theft. Illustrative only.

How to tell if you are carrying this

You do not need to fire a real exploit at your metadata endpoint to know whether you are exposed. The exposure is two readable facts: which of your AI services make server-side fetches, and what version each runs.

1. Inventory the fetchers. Walk your AI and agent footprint for anything that takes a URL or host and retrieves it server-side: multimodal image loaders, web and document loaders in retrieval pipelines, MCP HTTP servers, crawlers, link-preview and screenshot helpers. Each is an SSRF candidate by construction, because fetching a caller-influenced URL is its whole job.
2. Version-check each against the fixed builds. LMDeploy before 0.12.3, mcp-atlassian before 0.17.0, and Crawl4AI before 0.8.9 are the named cases, but the class is far broader. Version is the highest-signal fact, usually a one-line query against the service or its lockfile.
3. Prove egress with a responder you control, not real IMDS. Point the fetch at an internal HTTP responder you own and watch whether the request arrives. If it does, the service will follow a link into internal space, and the metadata endpoint is one such link. This confirms the exposure without ever reading a real credential.

The fetch is the feature. Every AI server is supposed to go get a URL for you. The bug is that so many of them will go get 169.254.169.254 too.

What to do about it

How Celvex catches this

This class slipped through because a URL fetcher does not look like an attack surface. It looks like a convenience. But a convenience that runs server-side with a cloud identity attached is exactly the shape of an SSRF primitive, and the AI boom shipped that shape by the thousand. Treat every server-side fetch as hostile by default about where it points, and remember that the one destination you must always refuse is the one that answers with credentials.

Verifiable security. Find the fetchers, prove the egress against a responder you own, fix the validation and the metadata configuration, and verify the path is closed. That is what we ship.