OpenClaw Open Door: SSRF in Your Personal AI Assistant

We all love the idea of an autonomous AI assistant. A digital butler that can browse the web, read documentation, and download images for us. It feels like the future. But when you give a piece of software the ability to make HTTP requests on your behalf, you are effectively handing it a web browser running inside your private network perimeter. If you don't put a leash on that browser, it doesn't just work for you—it works for anyone who can talk to it.

OpenClaw is exactly that: a TypeScript-based AI assistant that integrates with tools like Deepgram, OpenAI, and Google. It features an "Image Tool" and a "Web Fetch Tool" designed to grab content from the internet. The problem? It didn't distinguish between "the internet" and "your internal network."

This vulnerability is a classic tale of implicit trust. The developers assumed that if a user (or an autonomous agent) asked to fetch a URL, they meant a public website. They didn't anticipate that an attacker might ask the AI to fetch http://localhost:8080/admin or http://169.254.169.254/latest/meta-data/. This is SSRF 101: turning the server into a proxy for the attacker.

The root cause here is deceptively simple: the use of a standard HTTP client without egress filtering. In the JavaScript/TypeScript ecosystem, fetch (or libraries like undici and axios) is designed to be helpful. You give it a URL, and it handles DNS resolution, connection establishment, and redirects automatically. For a developer, this is great. For a security engineer, this is a nightmare.

Prior to the fix, OpenClaw's tools effectively did this:

// The vulnerable logic (simplified)
async function fetchImage(url: string) {
  const response = await fetch(url);
  return await response.blob();
}

There were no checks on where url actually pointed. If you passed http://google.com, it worked. If you passed http://127.0.0.1:22, it might hang or error out, revealing the port status. If you passed a cloud metadata URL, it would happily return the credentials. The application was checking the inputs (maybe ensuring it looked like a string), but it wasn't checking the destination.

The fix, implemented primarily by Peter Steinberger in commits 81c68f582d4a9a20d9cca9f367d2da9edc5a65ae and 9bd64c8a1f91dda602afc1d5246a2ff2be164647, is a masterclass in defensive programming against SSRF. They didn't just add a regex to block "localhost". They built a dedicated fetchWithSsrFGuard utility.

Here is the logic flow of the new guard:

Key technical components of the fix:

1. DNS Pinning: To prevent DNS Rebinding attacks (where a domain resolves to a public IP during the check but a private IP during the fetch), the fix resolves the IP first using resolvePinnedHostname. It then creates a custom undici dispatcher that forces the connection to that specific, validated IP.

2. Strict IP Blocklisting: The resolved IP is checked against a comprehensive list of restricted ranges, including RFC 1918 (Private), RFC 4193 (Unique Local), and IPv4-mapped IPv6 addresses. Explicit blocks were added for metadata.google.internal.

3. Manual Redirect Handling: The fetch option redirect: 'manual' is used. The code manually processes Location headers, re-validating the new target against the full SSRF policy before following. This prevents open redirect bypasses.

Let's assume we are attacking a version of OpenClaw running on an AWS EC2 instance. Our goal is to steal the IAM role credentials attached to the instance.

We don't need a complex binary exploit. We just need to speak the AI's language. We send a tool call request (or prompt the agent to generate one) targeting the Image Tool.

The Payload:

{
  "tool": "image_tool",
  "parameters": {
    "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
  }
}

The Execution Flow:

1. The Image Tool receives the URL.
2. It attempts to fetch the resource, expecting a JPG or PNG.
3. The request goes to the AWS Instance Metadata Service (IMDSv1).
4. IMDS replies with the name of the IAM role (e.g., production-role).
5. The attacker sends a second request: .../security-credentials/production-role.
6. The tool fetches the JSON blob containing AccessKeyId, SecretAccessKey, and Token.

Even if the tool errors out because "this JSON isn't an image," the error message in the logs or the agent's context window often includes the "invalid" content—giving the attacker exactly what they wanted.

The impact of SSRF in a cloud-native AI assistant cannot be overstated. It is rarely just about port scanning.

1. Cloud Account Takeover: As demonstrated above, accessing the instance metadata service often leads to full compromise of the cloud environment. If the attached role has S3 access, the attacker has your data. If it has EC2 admin rights, they own your infrastructure.

2. Internal Network Reconnaissance: OpenClaw often runs behind firewalls. An attacker can use it to map out internal microservices, finding unauthenticated Redis instances, Elasticsearch clusters, or internal admin panels that were never meant to see the public internet.

3. Localhost Exposure: Developers frequently run these assistants locally. An SSRF here could access local development servers (e.g., localhost:3000) or the Docker API, potentially allowing the attacker to escape the container or execute code on the developer's machine.

The OpenClaw team, specifically via the work in version v2026.2.14, has deployed a defense-in-depth fix. They realized that regex filters on URLs are insufficient because 127.1 and 2130706433 are both valid ways to say 127.0.0.1.

Mitigation Strategy:

• Upgrade Immediately: Users must upgrade to v2026.2.14 or later. The initial fix in v2026.2.2 was good, but the subsequent hardening closed edge cases involving IPv6 mapping.
• Network Segmentation: Even with the patch, run your AI assistants with the principle of least privilege. Do not give the container/VM access to sensitive internal networks if it doesn't need it.
• IMDSv2: Enforce IMDSv2 on AWS. This requires a session token header (X-aws-ec2-metadata-token) which a standard fetch request (controlled by an attacker via URL only) cannot easily spoof.