CVE-2026-41481

What it actually does

A Server-Side Request Forgery (SSRF) vulnerability exists in the `HTMLHeaderTextSplitter.split_text_from_url()` function of the `langchain-text-splitters` library. The function validates the initial URL but fails to re-validate the target URL after an HTTP redirect. This allows an attacker to provide a URL that redirects to an arbitrary internal network address, including localhost or cloud provider metadata services. The application server will then make a request to this internal endpoint, bypassing network controls and allowing the attacker to scan internal networks and access sensitive data from services not intended to be publicly exposed.

Why it matters to the business

This vulnerability can lead to the exfiltration of highly sensitive internal data, such as cloud infrastructure credentials, database connection strings, internal API keys, and other proprietary information. If an attacker successfully steals these secrets, they could gain further access to cloud environments, move laterally within the network, disrupt services, or cause a significant data breach. The financial and reputational damage from such a compromise can be substantial, even though exploiting it requires an application to expose the fetched content back to the user.

How an attack unfolds

An attacker identifies a web application that uses a vulnerable version of LangChain to process content from user-supplied URLs. The attacker crafts a URL on a server they control. This URL appears benign and passes the initial validation. When the application's backend server requests this URL, the attacker's server responds with an HTTP redirect (e.g., 301 or 302) to a sensitive internal endpoint, such as the AWS metadata service at `http://169.254.169.254/latest/meta-data/`. The vulnerable library follows this redirect without validation and fetches the content from the internal service. If the application is designed to return the processed content to the user, the attacker receives the sensitive data, such as temporary IAM credentials, from the metadata service.

How to fix it

Upgrade the `langchain-text-splitters` package to version 1.1.2 or later. This can be done using a package manager like pip: `pip install --upgrade langchain-text-splitters>=1.1.2`. If an immediate upgrade is not feasible, implement strict egress filtering rules on application hosts to block all outbound traffic to known cloud metadata IP addresses (e.g., 169.254.169.254) and other sensitive internal IP ranges, unless explicitly required for business operations.

How to confirm the fix worked

To confirm the fix, verify that the installed version of `langchain-text-splitters` is 1.1.2 or newer by running `pip show langchain-text-splitters` or an equivalent command for your environment's package manager. To test for the vulnerability, you can write a test script that calls `HTMLHeaderTextSplitter.split_text_from_url()` with a URL that redirects to a controlled internal endpoint (e.g., `http://127.0.0.1`). On a vulnerable system, this will result in a request to the local service. On a patched system, the operation should fail or be blocked.

Typical attack path

1. An attacker identifies a target application using a vulnerable version of `langchain-text-splitters` that processes URLs.
2. The attacker sets up a web server that responds to requests with an HTTP redirect to a sensitive internal target (e.g., a cloud metadata service).
3. The attacker submits their malicious URL to the vulnerable application.
4. The application's backend validates the initial URL, which passes.
5. The backend server makes a request to the attacker's URL and receives the redirect.
6. The vulnerable library follows the redirect and makes a request to the internal service, bypassing firewall rules.
7. The internal service responds with sensitive data (e.g., cloud credentials).
8. The application processes this sensitive data and, if designed to do so, returns it to the attacker, completing the data exfiltration.

How to detect it

To detect potential exploitation, monitor outbound network traffic from servers running LangChain applications. Look for HTTP/HTTPS requests to sensitive IP addresses that should not be accessed by the application, such as cloud metadata services (169.254.169.254 for AWS/Azure/GCP, metadata.google.internal for GCP), loopback addresses (127.0.0.1), or other private IP ranges (RFC 1918). Correlate these network events with application logs. A request to one of these destinations immediately following a request to an unknown external domain could indicate an exploit attempt involving a malicious redirect.

• GET /latest/meta-data/
• Host: 169.254.169.254
• GET /computeMetadata/v1/
• Host: metadata.google.internal
• X-Google-Metadata-Request: True
• GET /metadata/instance

What your security team should do

• Immediately identify all applications using the `langchain-text-splitters` library and prioritize upgrading them to version 1.1.2 or later.
• If patching is delayed, enforce strict egress network policies on application servers to deny requests to cloud metadata endpoints and internal-only services.
• Review network and application logs for anomalous outbound requests from application servers to internal IP addresses (e.g., 127.0.0.1, 169.254.169.254), which could indicate past exploitation attempts.
• Advise developers to be cautious with libraries that fetch remote resources and ensure that all redirects are validated against an allow-list of domains or IP addresses.