High

LangChain Recursive URL Loader SSRF to Internal Target

An AI agent that fetches web pages on your behalf can be handed a crafted URL that redirects it to internal network addresses or cloud credential endpoints instead of the public page it expects. This is a known flaw in older LangChain recursive URL loader versions and lets an outsider use your agent as a proxy into your own infrastructure.

How the attack works

An attacker supplies or influences a URL passed to LangChain's recursive URL loader (versions before 0.0.317). The URL looks like a normal fetch request but is crafted - plainly or via encoding tricks like hex/octal IP literals, DNS-rebinding domains, or lookalike hostnames - to resolve to loopback, private-network, link-local, cloud metadata, or internal cluster addresses. The loader follows it and the agent's outbound request lands on an address it was never meant to reach, such as a cloud instance-metadata service that hands back credentials. The detection flags a single such request when it matches known fetch-intent parameters, request-body URL fields, direct metadata-endpoint paths, or SSRF-filter-bypass host patterns.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID
7f3c1d92-6a4e-4b18-9c05-2e8d5a4f1b63
Severity
High

Why it matters

Successful exploitation can expose cloud credentials from instance metadata services or let an attacker reach internal-only systems (databases, admin panels, cluster services) that should not be internet-accessible, using the agent as an unwitting proxy.

What you can do

  • →Upgrade LangChain to 0.0.317 or later where this SSRF was fixed.
  • →Restrict the agent's outbound network access with an egress allowlist so it cannot reach loopback, RFC1918, link-local, or cloud metadata addresses.
  • →Block or firewall the cloud metadata endpoint (e.g. 169.254.169.254) from workloads that don't need it, or require IMDSv2/token-based access.
  • →Review any legitimate renderer, screenshot, or link-preview services that take a URL parameter, since these can look identical to this attack pattern and need separate validation of the target host.

Known benign look-alikes

  • Cloud SDK credential refresh from an agent running on EC2/GCE/Azure - an IMDSv1 GET to 169.254.169.254/latest/meta-data/iam/security-credentials/ is normal for boto3, google-auth and the Azure identity libraries and will match sel_metadata_fetch. This is why the rule is report-only.
  • Developers using nip.io, sslip.io, lvh.me or localtest.me to obtain wildcard DNS and local TLS certificates during development; these resolve to loopback by design and match sel_rebind_oob_host.
  • Legitimate internal renderer, screenshot, link-preview or reverse-proxy services invoked as https://renderer.corp/render?url=http://reports.internal/page - the request shape is indistinguishable from SSRF at a single event.
  • Kubernetes in-cluster service discovery where a *.svc.cluster.local URL is passed as a query parameter to an API gateway.
  • Security research or advisory-summarisation agents that quote SSRF payload URLs in a request body; mitigated by requiring both a CVE/GHSA identifier and advisory prose (filter_vuln_id and filter_advisory_text) before suppressing.
  • Documentation, IaC templates and config scaffolds containing unresolved URL placeholders; mitigated by filter_placeholder.

References