# LangChain Recursive URL Loader SSRF to Internal Target

- **Severity:** High
- **Signature ID:** `7f3c1d92-6a4e-4b18-9c05-2e8d5a4f1b63`
- **CVEs:** CVE-2023-46229

## Summary

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.

## 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

- https://nvd.nist.gov/vuln/detail/CVE-2023-46229
- https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
- https://owasp.org/Top10/A01_2021-Broken_Access_Control/

---
Source: https://www.netzilo.com/threats/langchain-recursive-url-loader-ssrf