CVE-2026-27795: 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