CVE-2026-26013

What it actually does

LangChain versions prior to 1.2.11 can perform unintended outbound network requests while estimating token counts for vision-capable chat messages. Specifically, ChatOpenAI.get_num_tokens_from_messages() processes user-supplied message content containing image_url values and fetches those URLs without sufficient validation. If untrusted users can influence image_url fields and the application calls this token-counting method, an attacker can cause the server-side application to request attacker-chosen URLs. The primary impact is SSRF with low availability impact: internal HTTP endpoints, cloud metadata services, loopback services, or otherwise non-public resources may be contacted from the application’s network location. The published CVSS is low, exploitation is marked as not mature, EPSS is low, and it is not listed in CISA KEV; however, exposure depends heavily on whether the application accepts untrusted multimodal inputs and has access to sensitive internal network endpoints.

Why it matters to the business

Affected LLM applications may be abused to make unauthorized outbound requests from trusted infrastructure. In practical terms, this can lead to internal service probing, cloud metadata access attempts, unexpected traffic to internal systems, and potential service degradation if attackers force repeated slow or large image fetches during token counting. The risk is lower than many SSRF issues because the known impact is limited and exploitation conditions are specific, but organizations using LangChain in internet-facing or partner-facing AI workflows should prioritize remediation because LLM applications often sit near sensitive APIs, credentials, and internal services.

How an attack unfolds

An attacker first identifies an application that accepts chat messages or multimodal content and uses LangChain’s ChatOpenAI integration to estimate token counts before sending requests to a vision-enabled model. The attacker submits a crafted message containing an image_url value that points to a target URL under the attacker’s control, a private network address, a loopback address, or a cloud metadata endpoint. When the vulnerable application invokes get_num_tokens_from_messages(), LangChain attempts to retrieve the supplied image URL as part of token calculation. The request originates from the vulnerable server, not from the attacker’s browser, allowing the attacker to test reachability of internal resources or trigger requests to sensitive network locations. Depending on application logging and response handling, the attacker may infer success from timing, error messages, request callbacks to attacker infrastructure, or changes in application behavior. There are no named threat actors or known ransomware campaigns associated with this issue in the provided intelligence.

How to fix it

Upgrade LangChain to version 1.2.11 or later. For source deployments, ensure the code includes the upstream fix at commit 524e1dab5e7c8229bd78be3c13ab38ac93a6216b. If immediate upgrade is not possible, avoid calling ChatOpenAI.get_num_tokens_from_messages() on untrusted messages containing image_url values, or strip image_url content before token counting. Enforce strict URL allowlisting for image retrieval, permitting only expected public domains and HTTPS where possible. Block access from application workloads to loopback, link-local, RFC1918 private ranges, cloud metadata services, and internal control-plane endpoints using egress firewall rules, service mesh policy, or cloud network controls. Configure HTTP clients used by the application to reject redirects to private networks, enforce short timeouts, limit response size, and disallow non-HTTP(S) schemes.

How to confirm the fix worked

Confirm dependency versions in all build manifests, lockfiles, containers, and deployed artifacts show LangChain 1.2.11 or later, or verify the presence of commit 524e1dab5e7c8229bd78be3c13ab38ac93a6216b in source-based deployments. Review application code for direct or indirect use of ChatOpenAI.get_num_tokens_from_messages() on untrusted user input. Perform a controlled test in a non-production environment by submitting an image_url pointing to an approved callback server and verifying that vulnerable versions make an outbound request while fixed versions do not fetch arbitrary URLs during token counting. Validate that egress controls block requests to 169.254.169.254, 169.254.170.2, localhost, and RFC1918 ranges from the application runtime. Confirm that redirects from allowed public URLs to private addresses are also blocked.

Typical attack path

1. Find an application using LangChain ChatOpenAI with support for user-controlled vision or image inputs.
2. Submit chat content containing an image_url field that references an attacker-controlled URL to confirm server-side fetching.
3. Replace the URL with internal, loopback, link-local, or cloud metadata addresses to test SSRF reachability.
4. Observe callbacks, timing differences, application errors, or logs exposed through the application to infer whether requests succeeded.
5. Repeat requests against internal endpoints or metadata services, or use many slow/large responses to create limited availability impact.

How to detect it

To determine whether exploitation already occurred, focus on outbound network activity from applications running LangChain and handling multimodal or image-capable chat input. Review application logs for messages containing image_url fields with link-local, loopback, private IP, unusual hostnames, encoded URLs, redirects, or nonstandard ports. Examine HTTP client logs, reverse proxy egress logs, firewall logs, VPC flow logs, DNS resolver logs, service mesh telemetry, and cloud workload metadata access logs for requests originating from the application runtime to internal or metadata endpoints. Look for outbound requests occurring immediately after chat submissions or token-counting operations, especially requests to attacker-controlled domains followed by probes to private addresses. If centralized logs include exceptions, search for URL fetch errors, connection timeouts, redirect errors, DNS failures, or refused connections associated with get_num_tokens_from_messages. Because no public exploit kit or actor-specific indicators are provided, detections should be behavior-based rather than tied to malware or campaign infrastructure.

• get_num_tokens_from_messages
• ChatOpenAI.get_num_tokens_from_messages
• image_url
• http://169.254.169.254
• https://169.254.169.254
• http://169.254.170.2
• https://169.254.170.2
• metadata.google.internal
• /latest/meta-data/
• /computeMetadata/v1/
• Metadata-Flavor: Google
• http://127.0.0.1
• http://localhost
• http://0.0.0.0
• http://10.
• http://172.16.
• http://172.17.
• http://172.18.
• http://172.19.
• http://172.20.
• http://172.21.
• http://172.22.
• http://172.23.
• http://172.24.
• http://172.25.
• http://172.26.
• http://172.27.
• http://172.28.
• http://172.29.
• http://172.30.
• http://172.31.
• http://192.168.
• http://[::1]
• file://
• gopher://

What your security team should do

• Inventory applications using LangChain, especially internet-facing LLM chat, agent, or multimodal workflows that accept user-supplied image URLs.
• Upgrade affected LangChain deployments to 1.2.11 or later, or deploy source code containing commit 524e1dab5e7c8229bd78be3c13ab38ac93a6216b.
• Add egress deny rules from AI application workloads to cloud metadata IPs, loopback, link-local, and private address ranges unless explicitly required.
• Search code for ChatOpenAI.get_num_tokens_from_messages() and verify it is not invoked on untrusted image_url values without validation.
• Add SSRF-safe URL validation, redirect handling, request timeouts, and response-size limits to any application component that retrieves remote media.
• Review historical application, proxy, DNS, firewall, and cloud metadata access logs for suspicious outbound requests originating from LLM application workloads.
• Create SIEM detections for application-originated requests to metadata services, localhost, RFC1918 networks, and unusual image_url values in chat request logs.