Browser-Use Agents and Server-Side Request Forgery: Old Vulns, New Vectors
Browser-Use Agents and Server-Side Request Forgery: Old Vulns, New Vectors
SSRF is not new. It’s been on the OWASP Top 10 since 2021, it’s been in every pentester’s playbook for a decade, and it’s the reason you’re not supposed to let user input control outbound HTTP requests from your server. We know how to prevent it. We know how to test for it. We’ve written the cheat sheets, the detection rules, the WAF signatures.
And then we gave AI agents a browser and told them to “go look things up.”
SSRF is back, and this time it’s wearing a trench coat made of natural language.
The Old SSRF: A Quick Refresher
Classic SSRF is straightforward: an application takes a URL from user input and makes a server-side request to it. The attacker supplies http://169.254.169.254/latest/meta-data/ instead of a legitimate URL. The server dutifully fetches AWS credentials from the instance metadata service and hands them to the attacker. Game over.
Defences are well-understood: validate URLs against allowlists, block private IP ranges, resolve DNS before making the request to prevent rebinding, restrict egress at the network level. This is AppSec 101.
But those defences assumed something: that URLs would arrive as URLs, in URL-shaped fields, through parseable HTTP parameters.
That assumption no longer holds.
The New Vector: AI Agents as SSRF Proxies
An AI agent with browsing capabilities is, architecturally, an SSRF vulnerability by design. Its entire purpose is to receive instructions in natural language and make HTTP requests to arbitrary destinations. The “user input” isn’t a URL parameter — it’s a sentence like “check the internal admin dashboard” or “fetch this document for me.”
The agent dutifully translates that into an HTTP request. And if nobody told it that http://localhost:8080/admin is off-limits, it will happily go there.
This isn’t theoretical. Let me walk you through what’s already happening.
Real-World Evidence: It’s Already Being Exploited
1. Pydantic AI — CVE-2026-25580 (CVSS 8.6)
In February 2026, Pydantic AI — a widely-used framework for building AI agents — disclosed CVE-2026-25580, a textbook SSRF vulnerability in its URL download functionality. The download_item() helper fetched content from URLs without validating that the target was a public address.
Any application accepting message history from untrusted sources (chat interfaces, Vercel AI SDK integrations, AG-UI protocol implementations) was vulnerable. An attacker could submit a message with a file attachment pointing at:
http://169.254.169.254/latest/meta-data/iam/security-credentials/And the server would fetch AWS IAM credentials and return them. Multiple model integrations were affected — OpenAI, Anthropic, Google, xAI, Bedrock, and OpenRouter all had download paths that could be abused.
The fix? Comprehensive SSRF protection: blocking private IPs, always blocking cloud metadata endpoints, validating redirect targets, resolving DNS before requests. Standard SSRF defences that should have been there from day one. The fact that a framework built specifically for AI agents shipped without basic SSRF protection tells you everything about the current state of agent security.
2. Tencent Xuanwu Lab — Server-Side Browser Kill Chains
Tencent’s Xuanwu Lab published a white paper on AI web crawler security in February 2026 that reads like a horror story. They tested server-side browsers across multiple AI products and found remote code execution vulnerabilities in every single one. The affected products collectively serve over a billion users.
Their four documented attack cases expose a pattern:
| Case | Entry Point | Bypass Method | Impact |
|---|---|---|---|
| 1 | AI search with URL allowlist | 302 redirect via allowlisted site | RCE, no sandbox |
| 2 | AI reading + sharing + screenshot | Chained features to bypass domain allowlist | SSRF to cloud metadata |
| 3 | URL access with script filtering | <img onerror> bypassed <script> filter | RCE via N-day chain |
| 4 | Hidden backend indexing crawler | No bypass needed — no defences | RCE, no sandbox |
Case 4 is particularly grim: a hidden backend crawler that batch-fetched URLs users had queried — invisible to frontend security, undocumented, running an outdated browser with no sandbox. The attacker didn’t even need to bypass anything.
The Xuanwu team puts it bluntly: “When you launch a browser instance, you are not starting a simple web browsing tool — you are launching a ‘micro operating system.’ A vulnerability in any single component could lead to remote code execution.”
3. Unit 42 — Indirect Prompt Injection as SSRF Delivery Mechanism
Palo Alto’s Unit 42 published research in March 2026 documenting web-based indirect prompt injection (IDPI) attacks observed in the wild. Not proof-of-concept. Not lab demos. Production attacks.
Their taxonomy maps the full kill chain from SSRF’s perspective:
- Forced internal requests: Embedded prompts in web pages instructing agents to access
http://localhost, internal services, and cloud metadata endpoints - Unauthorized transactions: Prompts directing agents to visit Stripe payment URLs and PayPal links to initiate financial transactions
- Data exfiltration: Instructions to collect environment variables, credentials, and contact lists — then exfiltrate via URL-encoded requests
- Data destruction: Commands to
rm -rfand fork bombs targeting backend infrastructure
The delivery methods are creative: zero-width Unicode characters, CSS-hidden text, Base64-encoded payloads assembled at runtime, SVG encapsulation, HTML attribute cloaking. 85% of the jailbreaks were social engineering — framing destructive commands as “security updates” or “compliance checks.”
The kicker: one attacker embedded 24 separate prompt injection attempts in a single page, using different delivery methods for each one. If even one bypasses the model’s safety filters, the attack succeeds.
4. Browserbase — “One Malicious <div> Away From Going Rogue”
Browserbase’s February 2026 analysis frames the problem with precision: “Every webpage an agent visits is a potential vector for attack.” They cite the PromptArmor research on Google’s Antigravity IDE, where an indirect prompt injection hidden in 1-point font inside an “implementation guide” successfully exfiltrated environment variables by encoding them as URLs and sending them via the browser agent’s own network requests.
That’s SSRF triggered by reading a document. The URL didn’t arrive as a URL. It arrived as invisible text on a web page.
Why Traditional SSRF Defences Fail Against Agents
The fundamental problem: SSRF defences are designed to protect applications, not autonomous decision-makers.
| Traditional Defence | Why It Fails With Agents |
|---|---|
| URL allowlists | Agents generate URLs dynamically from natural language — no static list covers the infinite space of valid requests |
| Input validation on URL parameters | The “input” is a sentence, not a URL. The URL is constructed internally by the agent |
| WAF signatures | Natural language payloads don’t match traditional SSRF patterns |
| DNS pre-resolution | Only works if you control the HTTP client — many agent frameworks use browsers that handle DNS independently |
| Egress filtering | Agent needs internet access to function — blocking egress breaks the core use case |
| IP blocklists | Only effective if applied at the HTTP client level before the request is made — agents using embedded browsers bypass application-layer controls |
The Tencent Xuanwu research adds another dimension: even when enterprises implement URL allowlists, they’re trivially bypassed. A 302 redirect from an allowlisted domain to an attacker-controlled page defeats the entire scheme. The SSRF isn’t in the first request — it’s in the redirect chain that follows.
The Attack Surface Is Bigger Than You Think
SSRF in the context of browser-use agents isn’t just about fetching cloud metadata. The attack surface includes:
- Cloud metadata services: AWS IMDSv1 (
169.254.169.254), GCP, Azure, Alibaba Cloud — stealing IAM roles, service account tokens, API keys - Internal APIs and admin panels: Accessing unauthenticated internal services that trust requests from within the network perimeter
- Database ports: Probing internal
MySQL:3306,Redis:6379,PostgreSQL:5432— extracting data from services that don’t require auth onlocalhost - Container orchestration: Accessing Kubernetes API servers, Docker sockets, etcd — pivoting to full cluster compromise
- Other agents: In multi-agent architectures, a compromised agent can SSRF into other agents’ API endpoints, creating cascading compromise
- Data exfiltration via URL encoding: The PromptArmor/Antigravity technique — embedding stolen data in outbound URL parameters, effectively using the agent as a covert channel
The Xuanwu team found that server-side browser containers were often deployed in the same network segment as production databases, task schedulers, and model inference nodes. Zero network isolation. Once the browser was compromised, lateral movement was trivial.
What Actually Works
If you’re deploying agents with browsing capabilities, here’s what you need — not principles, but concrete controls:
1. Network Isolation (Non-Negotiable)
Browser agents must run in isolated network zones. Egress to the internet: allowed. Access to internal services, metadata endpoints, private IP ranges: blocked at the infrastructure level. Kubernetes NetworkPolicies, separate VPCs, cloud security groups. This is the single most effective control — if the agent can’t reach 169.254.169.254, stealing metadata credentials is off the table regardless of what the LLM is tricked into doing.
2. SSRF Protection at the HTTP Client Level
Every HTTP request the agent makes should pass through a hardened client that:
- Resolves DNS before connecting (prevents rebinding)
- Blocks private IP ranges (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.0/8,169.254.0.0/16) - Always blocks cloud metadata endpoints, even if “allow-local” is configured
- Validates every redirect target, not just the initial URL
- Restricts protocols to
http://andhttps://only
Pydantic AI’s post-CVE fix is a good reference implementation.
3. Browser Sandboxing (Never Disable It)
The Tencent research found that multiple AI products disabled Chrome’s sandbox (--no-sandbox) to resolve container compatibility issues. This is catastrophic. Fix the container configuration instead: add the required seccomp profiles, grant CAP_SYS_ADMIN if necessary, configure user namespaces properly. The sandbox is the last line of defence against RCE — removing it turns every browser vulnerability into a full server compromise.
4. Instance Isolation
Each browsing task should use an independent, ephemeral browser instance that’s destroyed after completion. This prevents cross-task contamination, stops persistent compromise, and eliminates credential leakage between sessions. Browserbase’s approach of dedicated VMs per session with automatic teardown is the right model.
5. Attack Surface Reduction
Disable everything the agent doesn’t need: WebGL, WebRTC, PDF plugins, extensions. If performance allows, run with --jitless to eliminate the V8 JIT compiler — which accounts for roughly 23% of Chrome’s high-severity CVEs. Tencent’s analysis shows that disabling WebGL/GPU and JIT alone eliminates nearly 40% of browser vulnerability surface.
6. Runtime Behaviour Control
Tencent open-sourced SEChrome, a protection layer that monitors browser process system calls and enforces allowlists for file access, process execution, and network requests. Even if an attacker achieves RCE inside the browser, they can’t read sensitive files, execute arbitrary commands, or access the network beyond permitted destinations. Every tested exploit was blocked.
The Uncomfortable Truth
We’re deploying AI agents that have the browsing capabilities of a human user, the network access of a server-side application, and the security boundaries of neither. Every web page they visit is a potential attack payload. Every URL they construct is a potential SSRF. Every redirect they follow is a potential pivot point.
SSRF wasn’t “solved” in traditional web applications — it was managed through layers of controls that assumed a predictable request flow. AI agents break that assumption completely. The request flow is generated by a language model interpreting natural language from potentially hostile sources.
The good news: the defences exist. Network isolation, sandboxing, SSRF-hardened HTTP clients, instance isolation, runtime behaviour control. None of this is novel engineering. It’s applying established security patterns to a new deployment model.
The bad news: most agent deployments aren’t implementing any of it.
Old vulns don’t retire. They just find new hosts.
Sources & Further Reading:
- CVE-2026-25580 — Pydantic AI SSRF in URL Download Handling
- Tencent Xuanwu Lab — AI Web Crawler Security White Paper
- Unit 42 — Fooling AI Agents: Web-Based Indirect Prompt Injection in the Wild
- Browserbase — Your AI Browser Is One Malicious <div> Away From Going Rogue
- SEChrome — Server-Side Chrome Browser Protection (GitHub)
- DeepTeam — SSRF Red Teaming for AI Agents
