EUVD-2026-25635Severity by source
AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
DNS rebinding demands attacker DNS infrastructure and precise timing (AC:H); response body is Pillow-internal only, so I:N and A:N; blind probing warrants C:L.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
6Blast Radius
ecosystem impact- 5 pypi packages depend on langchain-openai (5 direct, 0 indirect)
Ecosystem-wide dependent count for version 1.1.14.
DescriptionGitHub Advisory
LangChain is a framework for building agents and LLM-powered applications. Prior to 1.1.14, langchain-openai's _url_to_size() helper (used by get_num_tokens_from_messages for image token counting) validated URLs for SSRF protection and then fetched them in a separate network operation with independent DNS resolution. This left a TOCTOU / DNS rebinding window: an attacker-controlled hostname could resolve to a public IP during validation and then to a private/localhost IP during the actual fetch.
AnalysisAI
DNS rebinding in langchain-openai before 1.1.14 allows an attacker-controlled hostname to bypass SSRF protection in the image token-counting code path, enabling blind probing of internal network services. The _url_to_size() helper performs URL validation and the subsequent HTTP fetch as two independent operations with separate DNS resolution, creating a TOCTOU race window that a malicious domain with a short TTL can exploit to redirect the fetch to a private or localhost address after passing the initial check. Practical impact is bounded: the HTTP response is consumed only by Pillow for image dimension extraction and is never returned or logged, making data exfiltration impossible; SSVC confirms no active exploitation, EPSS sits at the 8th percentile, and no public exploit code exists at time of analysis.
Technical ContextAI
The vulnerability is in libs/partners/openai/langchain_openai/chat_models/base.py within _url_to_size(), which is invoked by get_num_tokens_from_messages to measure image dimensions for token budget calculations. The root cause is CWE-918 (Server-Side Request Forgery) in its TOCTOU form: the function first calls validate_safe_url() to block private-range destinations, but then issues a completely independent httpx.get() call whose DNS resolution is separate from the validation step. An attacker who controls a domain sets a near-zero TTL and initially answers with a public IP to pass validation; before the second resolution occurs, the attacker flips the DNS record to a private RFC-1918 address, the cloud metadata endpoint 169.254.169.254, or a Kubernetes cluster-internal address. The affected CPE is cpe:2.3:a:langchain-ai:langchain-openai:*:*:*:*:*:*:*:* for all versions prior to 1.1.14. The fix (langchain-openai 1.1.14) replaces the validate-then-fetch pattern with SSRFSafeSyncTransport from langchain-core, which resolves DNS once, validates all returned IPs against a comprehensive policy, pins the TCP connection to that IP, and disables redirect following.
RemediationAI
Upgrade langchain-openai to version 1.1.14 or later and simultaneously upgrade langchain-core to 1.2.31 or later, as the fix depends on SSRFSafeSyncTransport introduced in that langchain-core release. The full advisory with patch details is at https://github.com/langchain-ai/langchain/security/advisories/GHSA-r7w7-9xr2-qq2r. If immediate patching is not possible, apply egress firewall rules on the application server to block outbound HTTP/HTTPS to RFC-1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), the APIPA/link-local range (169.254.0.0/16 including the AWS/GCP metadata endpoint 169.254.169.254), and the IPv6 loopback/ULA ranges; note that this control operates at the network layer and does not fix the TOCTOU race itself, so a sufficiently creative attacker with DNS infrastructure in a routable but sensitive IP space could still probe those ranges. As a secondary control, avoid exposing get_num_tokens_from_messages to untrusted user-provided image URLs without sanitizing the URL to a known-good allowlist before it reaches langchain-openai.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today