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

CWE-918 Server-Side Request Forgery (SSRF)