LangChain Community: redirect chaining can lead to SSRF bypass via RecursiveUrlLoader

Summary

A redirect-based Server-Side Request Forgery (SSRF) bypass exists in RecursiveUrlLoader in @langchain/community. The loader validates the initial URL but allows the underlying fetch to follow redirects automatically, which permits a transition from a safe public URL to an internal or metadata endpoint without revalidation. This is a bypass of the SSRF protections introduced in 1.1.14 (CVE-2026-26019).

Affected Component

• Package: @langchain/community
• Component: RecursiveUrlLoader
• Configuration: preventOutside (default: true) is insufficient to prevent this bypass when redirects are followed automatically.

Description

RecursiveUrlLoader is a web crawler that recursively follows links from a starting URL. The existing SSRF mitigation validates the initial URL before fetching, but it does not re-validate when the request follows redirects. Because fetch follows redirects by default, an attacker can supply a public URL that passes validation and then redirects to a private network address, localhost, or cloud metadata endpoint.

This constitutes a “check‑then‑act” gap in the request lifecycle: the safety check occurs before the redirect chain is resolved, and the final destination is never validated.

Impact

If an attacker can influence content on a page being crawled (e.g., user‑generated content, untrusted external pages), they can cause the crawler to:
- Fetch cloud instance metadata (AWS, GCP, Azure), potentially exposing credentials or tokens
- Access internal services on private networks (10.x, 172.16.x, 192.168.x)
- Connect to localhost services
- Exfiltrate response data through attacker-controlled redirect chains

This is exploitable in any environment where RecursiveUrlLoader runs with access to internal networks or metadata services, which includes most cloud-hosted deployments.

Attack Scenario

1. The crawler is pointed at a public URL that passes initial SSRF validation.
2. That URL responds with a 3xx redirect to an internal target.
3. The fetch follows the redirect automatically without revalidation.
4. The crawler accesses the internal or metadata endpoint.

Example redirector:

https://302.r3dir.me/--to/?url=http://169.254.169.254/latest/meta-data/

Root Cause

• SSRF validation (validateSafeUrl) is only performed on the initial URL.
• Redirects are followed automatically by fetch (redirect: "follow" default), so the request can change destinations without additional validation.

Resolution

Upgrade to @langchain/community >= 1.1.18, which validates every redirect hop by disabling automatic redirects and re-validating Location targets before following them.
- Automatic redirects are disabled (redirect: "manual").
- Each 3xx Location is resolved and validated with validateSafeUrl() before the next request.
- A maximum redirect limit prevents infinite loops.

Reources

• Original SSRF fix (CVE-2026-26019): enforced origin comparison and added initial URL validation
• https://github.com/langchain-ai/langchainjs/security/advisories/GHSA-gf3v-fwqg-4vh7