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.

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 .

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.

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.

Identified during internal review of media-download hardening.