CVE-2026-41481Patch(langchain / langchain-text-splitters)

Our CTI team identified a lot of activities targeting langchain-ai langchain-text-splitters (CVE-2026-41481) https://vuldb.com/vuln/359575/cti

CVE-2026-41481: langchain-text-splitters' HTMLHeaderTextSplitter.split_text_from_url() validated the URL, fetched it, and followed redirects without revalidating each hop. CWE-601 → CWE-918 chain. Patched in 1.1.2. Validate-then-fetch with redirects-on is the bug pattern.

GPT-5.5 went GA on Thursday. By Friday morning, LangChain shipped TWO SSRF fixes — CVE-2026-41481 (text-splitters, redirect bypass) and CVE-2026-41488 (langchain-openai, DNS-rebind/TOCTOU). Same week. Concurrent, not sequential. The lesson isn't the model:

LangChain CVE-2026-41481: The URL Was Validated. The Redirect Was Not. The URL passed the safety check. The redirect did not get one. CVE-2026-41481 was disclosed on April 24 against langchain-text-splitters versions before 1.1.2. CVSS 6.5. The HTMLHeaderTextSplitter.split_text_from_url function calls validate_safe_url on the input. Then it calls requests.get with redirects enabled by default. The 302 response and its Location header are never revalidated. An attacker hosts a benign-looking URL, returns a 302 pointing at 169.254.169.254, and the splitter quietly fetches cloud metadata into a Document object the application may surface back to the requester. The fix replaces requests.get with an SSRF-safe httpx transport that validates DNS results and pins connections to validated IPs on every request, including redirect targets. Most teams audit the agent. The pain is the framework one layer below it. LangChain is wired into thousands of agent deployments as a default. A single trusted helper that says "I check URLs" while the underlying HTTP library follows arbitrary redirects is the difference between a documented control and a real one. The validation ran. The validation was not enforced through the redirect chain. This is the second SSRF disclosure against a major AI inference and orchestration framework in the same week. LMDeploy was 7.5. LangChain is 6.5. Both of them collapse to "the framework fetched something on behalf of your agent and your perimeter never saw the egress." ### What it breaks - validate_safe_url creates a documented security control that does not function as documented. Teams that rely on framework-level URL validation as a control have a false positive in their control inventory. - Redirect chains from any attacker-controlled URL can point to 169.254.169.254 or internal RFC-1918 ranges. Cloud metadata, internal APIs, and Redis endpoints are all reachable through the validated-once path. - LangChain is embedded in thousands of agent deployments as a default dependency. A single patch gap across one transitive dependency exposes all downstream agents simultaneously. - Detection gap: The outbound request originates from the application server as a legitimate langchain-text-splitters call. No anomaly signal distinguishes an SSRF redirect from a normal document fetch in standard application logs. - Compliance exposure: SOC 2 CC6.6 requires that data processing is restricted to authorized purposes. Metadata exfiltration through a helper function that claims to validate URLs is an authorization control failure with no audit trail. ### What to do - Threat: Validated-Once SSRF via Redirect Chain: validate_safe_url ran on the input URL but the HTTP client followed 302 redirects without revalidation, meaning the security gate existed at the entry point only and the execution path had no boundary enforcement. - Start here: Upgrade langchain-text-splitters to 1.1.2 or later across all environments. Grep all agent codebases for HTMLHeaderTextSplitter.split_text_from_url usage before assuming patch coverage. [AI Agent Context Supply Chain Playbook](https://www.mrdecentralize.com/agentbook/playbook/playbook-context-supply-chain), 18 questions to stop data from becoming command. - Then: Audit all framework-level URL validation helpers across the dependency tree. Validate that redirect chains are blocked at the HTTP transport layer, not just at the input validation layer. - Operator connection: Any LangChain-based agent that fetches user-supplied URLs in a RAG or document-splitting pipeline is exposed. Scope review to any workflow where external URLs enter the context window. - Red team action: Run SSRF probe with a redirect chain from a controlled domain to 169.254.169.254 against all LangChain text-splitter endpoints. Confirm the fix is present by verifying httpx transport is the active HTTP client. ### Signal Breakdown - Architecture layer: L6 Tool and Integration Layer. - Attack surface: Framework URL validation helper that does not cover redirect targets, enabling SSRF into cloud metadata. - Playbooks: [AI Agent Context Supply Chain Playbook](https://www.mrdecentralize.com/agentbook/playbook/playbook-context-supply-chain). - Red team: SSRF redirect probe, httpx transport verification. - Frameworks: ASI09 (Supply Chain Vulnerabilities) / LLM02 (Sensitive Information Disclosure). **Source:** [GitLab Advisory Database, April 24, 2026](https://advisories.gitlab.com/pypi/langchain-text-splitters/GHSA-fv5p-p927-qmxr/) https://www.mrdecentralize.com/agentbook/playbook/playbook-context-supply-chain

CVE-2026-41481 Server-Side Request Forgery via URL Redirect in LangChain Text Splitters https://vulmon.com/vulnerabilitydetails?qid=CVE-2026-41481

CVE-2026-41481 LangChain is a framework for building agents and LLM-powered applications. Prior to langchain-text-splitters 1.1.2, HTMLHeaderTextSplitter.split_text_from_url() vali… https://www.cve.org/CVERecord?id=CVE-2026-41481