CVE-2026-107294: Pydantic AI: Unbounded memory use when downloading remote content via web_fetch or FileUrl

The helper read the full body, then applied content limits. The existing text-length limit only truncated after the whole body was in memory, and media downloads for ImageUrl, DocumentUrl, VideoUrl and AudioUrl had no wire-level cap at all. A single large response could grow memory without bound.

The attacker needs the agent to fetch their URL: through an untrusted prompt to an agent with the local web-fetch tool or WebFetch local fallback, or through a FileUrl that untrusted input influences. They host an endpoint that streams a very large body. The process is killed by the OOM killer or crashes, taking down other runs in the same worker. SSRF protections (scheme allowlist, private-IP and cloud-metadata blocking) are unaffected, and there is no confidentiality or integrity impact.

Affected: pydantic-ai and pydantic-ai-slim from 1.77.0 up to 1.107.2, and from 2.0.0b1 through 2.23.0. You are exposed if the app registers the local web-fetch tool and exposes the agent to untrusted prompts, or downloads large FileUrls influenced by untrusted input.

pip show pydantic-ai pydantic-ai-slim

Apps that fetch only developer-controlled URLs are not exposed to the model-chosen path.

Upgrade to 2.24.0 or later on v2, or 1.107.2 or later on v1:

pip install --upgrade pydantic-ai

Patched versions enforce a default 50 MiB cap on web-fetch and FileUrl downloads while streaming. Passing None to the limit restores the unbounded behavior, so avoid that for untrusted URLs. The advisory lists no other workaround.

Watch worker memory for sharp growth during a fetch, OOM kills and restarts of agent workers, and outbound connections to unfamiliar hosts that stay open while transferring large amounts of data. Compare with the URLs the agent was asked to fetch.

Summary

Several remote-content download paths in Pydantic AI buffered the entire HTTP response body into memory before enforcing any size limit. An application that exposes the local web-fetch tool (web_fetch_tool, or the WebFetch capability's local fallback) to untrusted prompts can be driven to fetch an attacker-chosen URL that streams a very large body, exhausting process memory and crashing the worker. The same unbounded buffering applied to FileUrl media downloads (ImageUrl, DocumentUrl, VideoUrl, AudioUrl).

This is an availability issue only. SSRF protections (scheme allowlist, private-IP and cloud-metadata blocking) are unaffected; there is no confidentiality or integrity impact.

Details

The download helpers read the full response body before applying content-size controls, so an existing text-length limit only truncated *after* the whole body was already in memory, and media downloads had no wire-level cap at all. A single large response could grow process memory without bound .

Who Is Affected

You are affected if your application registers the local web-fetch tool (or relies on the WebFetch capability's local fallback) and exposes the agent to untrusted prompts, or if it downloads large remote FileUrls influenced by untrusted input. Applications that only fetch developer-controlled URLs are not exposed to the model-chosen attack path.

Remediation

Upgrade to 2.24.0 or later (v2) or 1.107.2 or later (v1). Patched versions enforce a default 50 MiB cap on web-fetch and FileUrl downloads while streaming; pass None to the limit to restore the previous unbounded behavior.

Credits

Identified during internal review of media-download hardening.