CVE-2026-26013 is a low-severity (CVSS 3.7) Server-Side Request Forgery (SSRF) vulnerability in langchain-core. A fix is available for langchain-core — see the affected versions and patch details below.
LangChain affected by SSRF via image_url token counting in ChatOpenAI.get_num_tokens_from_messages
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-26013.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-26013 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 379,145 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
langchain-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Server-Side Request Forgery (SSRF) in ChatOpenAI Image Token Counting
Summary
The ChatOpenAI.get_num_tokens_from_messages() method fetches arbitrary image_url values without validation when computing token counts for vision-enabled models. This allows attackers to trigger Server-Side Request Forgery (SSRF) attacks by providing malicious image URLs in user input.
Severity
Low - The vulnerability allows SSRF attacks but has limited impact due to:
- Responses are not returned to the attacker (blind SSRF)
- Default 5-second timeout limits resource exhaustion
- Non-image responses fail at PIL image parsing
Impact
An attacker who can control image URLs passed to get_num_tokens_from_messages() can:
- Trigger HTTP requests from the application server to arbitrary internal or external URLs
- Cause the server to access internal network resources (private IPs, cloud metadata endpoints)
- Cause minor resource consumption through image downloads (bounded by timeout)
Note: This vulnerability occurs during token counting, which may happen outside of model invocation (e.g., in logging, metrics, or token budgeting flows).
Details
The vulnerable code path:
get_num_tokens_from_messages()processes messages containingimage_urlcontent blocks- For images without
detail: "low", it calls_url_to_size()to fetch the image and compute token counts _url_to_size()performshttpx.get(image_source)on any URL without validation- Prior to the patch, there was no SSRF protection, size limits, or explicit timeout
File: libs/partners/openai/langchain_openai/chat_models/base.py
Patches
The vulnerability has been patched in langchain-openai==1.1.9 (requires langchain-core==1.2.11).
The patch adds:
- SSRF validation using
langchain_core._security._ssrf_protection.validate_safe_url()to block:- Private IP ranges (RFC 1918, loopback, link-local)
- Cloud metadata endpoints (169.254.169.254, etc.)
- Invalid URL schemes
- Explicit size limits (50 MB maximum, matching OpenAI's payload limit)
- Explicit timeout (5 seconds, same as
httpx.getdefault) - Allow disabling image fetching via
allow_fetching_images=Falseparameter
Workarounds
If you cannot upgrade immediately:
- Sanitize input: Validate and filter
image_urlvalues before passing messages to token counting or model invocation - Use network controls: Implement egress filtering to prevent outbound requests to private IPs
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | langchain-core | all versions | 1.2.11pip install --upgrade 'langchain-core==1.2.11' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for langchain-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update langchain-core to 1.2.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-26013 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-26013 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-26013. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-26013 in your dependencies?
O3 Security finds CVE-2026-26013 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.