CVE-2026-27795: 
JavaScript vulnerability analysis and mitigation

CVE-2026-27795 is a redirect-based Server-Side Request Forgery (SSRF) bypass vulnerability in the RecursiveUrlLoader component of @langchain/community for Node.js. The loader validates the initial URL before fetching but allows the underlying fetch call to follow HTTP redirects automatically, enabling a transition from a validated public URL to an internal or cloud metadata endpoint without revalidation. This constitutes a bypass of the SSRF protections introduced in version 1.1.14 (CVE-2026-26019). Affected versions are all @langchain/community releases up to and including 1.1.17; the fix is available in 1.1.18. The vulnerability carries a CVSS v3.1 base score of 7.4 (High) per NVD, and 4.1 (Moderate) per the GitHub Security Advisory (GitHub Advisory, Red Hat CVE).

The root cause is a "check-then-act" race condition (CWE-918: Server-Side Request Forgery) in RecursiveUrlLoader. The validateSafeUrl() function is called only on the initial URL before the fetch request is issued; because fetch defaults to redirect: "follow", subsequent 3xx redirect hops are followed automatically without any re-validation of the Location header target. An attacker who can influence content on a crawled page (e.g., via user-generated content or an attacker-controlled external page) can embed a link to a public URL that passes initial validation and then issues a redirect to a private network address, localhost, or a cloud instance metadata endpoint such as http://169.254.169.254/latest/meta-data/. The advisory notes a concrete example redirector: https://302.r3dir.me/--to/?url=http://169.254.169.254/latest/meta-data/. The fix in 1.1.18 disables automatic redirects (redirect: "manual"), manually resolves each Location header, and calls validateSafeUrl() on every hop before proceeding, with a hard cap of 10 redirects to prevent infinite loops (GitHub Advisory, Fix Commit).

Successful exploitation allows an attacker to cause the LangChain application server to fetch cloud instance metadata endpoints (AWS IMDSv1 at 169.254.169.254, GCP, Azure equivalents), potentially exposing IAM credentials, session tokens, and other sensitive configuration data. Internal services on RFC 1918 address ranges (10.x, 172.16.x, 192.168.x) and localhost services are also reachable, enabling reconnaissance of internal infrastructure. The impact is limited to confidentiality — there is no integrity or availability impact — but credential exposure from cloud metadata services could enable lateral movement or privilege escalation within a cloud environment (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of active in-the-wild exploitation as of the time of disclosure (Feedly). The EPSS score is approximately 0.031%, reflecting low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires that an attacker be able to influence content on a page being crawled by RecursiveUrlLoader (e.g., placing a malicious link on a public page or user-generated content platform), and that a user or automated process trigger the crawl — meaning user interaction is required (GitHub Advisory).

1. Identify a target: Locate a LangChain-based application using RecursiveUrlLoader from @langchain/community <= 1.1.17 that crawls pages containing attacker-influenced content (e.g., a public forum, wiki, or user-generated content site).
2. Set up a redirect server: Configure a public URL that issues a 3xx redirect to an internal target. A ready-made service such as https://302.r3dir.me/--to/?url=http://169.254.169.254/latest/meta-data/ can be used, or deploy a simple HTTP server that responds with HTTP/1.1 302 Found and Location: http://169.254.169.254/latest/meta-data/.
3. Inject the malicious link: Embed the redirect URL as a hyperlink in content that will be crawled by the target application (e.g., post it on a page the crawler is known to index).
4. Trigger the crawl: Wait for or induce the application to run RecursiveUrlLoader against the page containing the injected link. The loader validates the public redirect URL (which passes), then fetch automatically follows the redirect to the internal metadata endpoint.
5. Exfiltrate data: The crawler fetches the internal endpoint response (e.g., AWS IAM credentials from http://169.254.169.254/latest/meta-data/iam/security-credentials/) and may store or log the content, which the attacker can then retrieve (GitHub Advisory).

• Network: Outbound HTTP requests from the application server to 169.254.169.254, 169.254.170.2, 100.100.100.200, metadata.google.internal, or RFC 1918 address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) originating from the Node.js process running LangChain.
• Network: HTTP requests to known open redirect services (e.g., 302.r3dir.me) followed immediately by requests to internal IP ranges from the same process.
• Logs: Application or access logs showing RecursiveUrlLoader fetching URLs that resolve to private or link-local IP addresses; HTTP 302/301/307/308 responses from external hosts followed by requests to 169.254.x.x or 192.168.x.x.
• Logs: Cloud provider access logs (AWS CloudTrail, GCP Audit Logs) showing unexpected calls to the instance metadata service (169.254.169.254) from the application host.
• Process: Unexpected network connections from the Node.js process to internal subnets or metadata endpoints not part of normal application traffic.

Primary remediation: Upgrade @langchain/community to version 1.1.18 or later, which disables automatic redirects, validates every Location header with validateSafeUrl() before following, and enforces a maximum of 10 redirects (GitHub Advisory, Fix Commit).

Workarounds (if immediate upgrade is not possible):

• Avoid using RecursiveUrlLoader on untrusted, user-influenced, or externally controlled content.
• Deploy network-level egress controls on the application server to block access to 169.254.0.0/16, RFC 1918 ranges, and other internal endpoints.
• Monitor application logs for redirect chains leading to internal addresses.

The vulnerability was reported by security researcher r3dbrothers and remediated by LangChain maintainer hntrl, who also authored the original SSRF hardening PR (#9990) that introduced the protections bypassed by this issue. A technical write-up was published at infinitsec.net shortly after disclosure, and a community article on dev.to titled "CVE-2026-27795: The Chain Breaker — Bypassing LangChain's SSRF Guards" provided additional context. Red Hat tracked the issue in their CVE database, indicating relevance to enterprise users of LangChain-based tooling (GitHub Advisory, Red Hat CVE).