CVE-2026-26019: 
JavaScript vulnerability analysis and mitigation

CVE-2026-26019 is a Server-Side Request Forgery (SSRF) vulnerability in the RecursiveUrlLoader class of LangChain's @langchain/community npm package (versions ≤ 1.1.13). The flaw allows an attacker who controls content on a crawled page to redirect the crawler to attacker-controlled domains or internal infrastructure, including cloud metadata services. It was disclosed and patched on February 11, 2026, with the fix released in version 1.1.14. The vulnerability carries a CVSS v3.1 base score of 4.1 (Moderate) (Github Advisory, LangChain Security Advisory).

The root cause is classified as CWE-918 (Server-Side Request Forgery). The RecursiveUrlLoader class used String.startsWith() to enforce its preventOutside option, which is intended to restrict crawling to the same origin as the base URL. This string-based check is trivially bypassed: a URL like https://example.com.attacker.com passes a startsWith("https://example.com") check, allowing the crawler to follow links to attacker-controlled domains. Additionally, the crawler performed no validation against private or reserved IP ranges (RFC 1918, loopback, link-local) or cloud metadata endpoints (e.g., 169.254.169.254), enabling SSRF to internal infrastructure. Exploitation requires an attacker to control content on a page being crawled (e.g., via user-generated content or a public forum) and a user to trigger the crawl (Github Advisory, LangChain PR #9990).

Successful exploitation can expose sensitive cloud infrastructure data, including IAM credentials and session tokens from AWS, GCP, and Azure metadata services (169.254.169.254, metadata.google.internal, etc.), as well as internal APIs and services on private networks (10.x, 172.16.x, 192.168.x) and localhost. The vulnerability's scope is marked as "Changed," meaning the impact extends beyond the vulnerable component itself to other systems accessible from the server running the crawler. While integrity and availability are not directly impacted, the confidentiality exposure — particularly credential theft from cloud metadata — could enable significant lateral movement and privilege escalation in cloud-hosted deployments (LangChain Security Advisory).

No public proof-of-concept exploit code has been confirmed, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.026% (2nd percentile), indicating a low near-term probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low privileges and user interaction (a user must trigger the crawler to visit an attacker-influenced page), which limits opportunistic exploitation but does not eliminate targeted attack scenarios in cloud environments.

1. Identify a target: Locate an application using @langchain/community ≤ 1.1.13 that employs RecursiveUrlLoader to crawl pages containing user-generated or externally influenced content.
2. Craft a malicious link for subdomain bypass: Place a hyperlink on a page the crawler will visit pointing to a domain that shares a string prefix with the target base URL (e.g., if the base URL is https://example.com, embed a link to https://example.com.attacker.com/exfil). The vulnerable startsWith() check will pass this URL as allowed.
3. Craft a malicious link for internal SSRF: Alternatively, embed a link directly to a cloud metadata endpoint (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/) or an internal RFC 1918 address (e.g., http://192.168.1.1/admin) on the crawled page.
4. Trigger the crawl: Cause a user or automated process to invoke RecursiveUrlLoader starting from a URL that leads to the attacker-controlled or influenced page.
5. Collect exfiltrated data: The crawler fetches the malicious URL and returns its content as a document. If targeting cloud metadata, the response may contain IAM credentials, session tokens, or instance configuration data that can be used for further access (LangChain Security Advisory, LangChain PR #9990).

• Network: Outbound HTTP requests from the application server to 169.254.169.254, 169.254.170.2, 100.100.100.200, or metadata.google.internal; requests to RFC 1918 addresses (10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x) or localhost/127.x.x.x originating from the Node.js process running LangChain.
• Network: Outbound requests to domains that share a string prefix with the application's own domain but resolve to external IPs (e.g., yourdomain.com.attacker.com).
• Logs: Application or web server logs showing RecursiveUrlLoader fetching URLs outside the expected domain scope, particularly to link-local or private IP ranges.
• Logs: Unexpected HTTP responses containing cloud provider metadata formats (JSON with fields like AccessKeyId, SecretAccessKey, Token) being processed by the application.

Upgrade @langchain/community to version 1.1.14 or later, which replaces the vulnerable startsWith() check with a strict origin comparison (new URL(link).origin === new URL(baseUrl).origin) and introduces a new @langchain/core/utils/ssrf module that blocks requests to cloud metadata endpoints, private IP ranges, localhost, and non-HTTP/HTTPS schemes before every fetch (LangChain Release, LangChain Security Advisory). For teams unable to upgrade immediately, avoid using RecursiveUrlLoader on untrusted or user-influenced content, and deploy network-level controls (firewall rules, egress filtering) to block the application server's access to cloud metadata endpoints and internal services.

The vulnerability received coverage from several security news outlets including GBHackers, CyberSecurityNews, and CyberPress, which highlighted the risk of SSRF in AI/LLM frameworks as a growing concern (GBHackers, CyberSecurityNews). The Hacker News weekly recap also mentioned the vulnerability in the context of the broader threat landscape. The fix was developed by contributor hntrl and reviewed by LangChain maintainer Christian Bromann, who noted it was "an excellent implementation of SSRF protection" (LangChain PR #9990).