@langchain/community

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

CVSS 4.1 (MEDIUM) — CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N ## Description The `RecursiveUrlLoader` class in `@langchain/community` is a web crawler that recursively follows links from a starting URL. Its `preventOutside` option (enabled by default) is intended to restrict crawling to the same site as the base URL. The implementation used `String.startsWith()` to compare URLs, which does not perform semantic URL validation. An attacker who controls content on a crawled page could include links to domains that share a string prefix with the target (e.g., `https://example.com.attacker.com` passes a `startsWith` check against `https://example.com`), causing the crawler to follow links to attacker-controlled or internal infrastructure. Additionally, the crawler performed no validation against private or reserved IP addresses. A crawled page could include links targeting cloud metadata services (`169.254.169.254`), localhost, or RFC 1918 addresses, and the crawler would fetch them without restriction. ## Impact An attacker who can influence the content of a page being crawled (e.g., by placing a link on a public-facing page, forum, or user-generated content) could cause the crawler to: - Fetch cloud instance metadata (AWS, GCP, Azure), potentially exposing IAM credentials and session tokens - Access internal services on private networks (`10.x`, `172.16.x`, `192.168.x`) - Connect to localhost services - Exfiltrate response data via attacker-controlled redirect chains This is exploitable in any environment where `RecursiveUrlLoader` runs on infrastructure with access to cloud metadata or internal services — which includes most cloud-hosted deployments. ## Resolution Two changes were made: 1. **Origin comparison replaced.** The `startsWith` check was replaced with a strict origin comparison using the URL API (`new URL(link).origin === new URL(baseUrl).origin`). This correctly validates scheme, hostname, and port as a unit, preventing subdomain-based bypasses. 2. **SSRF validation added to all fetch operations.** A new URL validation module (`@langchain/core/utils/ssrf`) was introduced and applied before every outbound fetch in the crawler. This blocks requests to: - **Cloud metadata endpoints:** `169.254.169.254`, `169.254.170.2`, `100.100.100.200`, `metadata.google.internal`, and related hostnames - **Private IP ranges:** `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `169.254.0.0/16` - **IPv6 equivalents:** `::1`, `fc00::/7`, `fe80::/10` - **Non-HTTP/HTTPS schemes** (`file:`, `ftp:`, `javascript:`, etc.) Cloud metadata endpoints are unconditionally blocked and cannot be overridden. ## Workarounds Users who cannot upgrade immediately should avoid using `RecursiveUrlLoader` on untrusted or user-influenced content, or should run the crawler in a network environment without access to cloud metadata or internal services.

CVSS 4.1 (MEDIUM) — CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N ## 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

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.