Validated Research Published: Aug 5, 2026

Pydantic AI Shows How Message History Can Become Server-Side Fetch Authority

CVE-2026-25580 let untrusted Pydantic AI message history and URL-based attachments cause the application server to fetch attacker-selected addresses. A crafted file URL could reach internal services, link-local cloud metadata, or other destinations unavailable to the external caller. Two later IPv6-transition bypasses affected applications that explicitly allowed local downloads. The case shows that a serialized conversation is not passive history when replaying it invokes server-side I/O.

Data ExfiltrationInput ValidationAgentic AIWeb Security
4 applicable AIDEFEND defenses
Source: Server-Side Request Forgery (SSRF) in URL Download Handling 
Author: Douwe Maan
Original article: Feb 6, 2026

Threat Analysis

  • The active input was a replayable conversation object. An application accepting untrusted message history could receive a URL-backed image, audio, video, or document. Pydantic AI's download_item() then fetched that URL with the server's network access.
  • The original issue required attacker-controlled history or URL parts. A file URL could point to localhost, a private service, or cloud metadata. Applications using only hardcoded or developer-controlled URLs were not affected by this path. Version 1.56.0 added scheme, address, DNS, and redirect checks.
  • Two narrower bypasses followed. CVE-2026-46678 and CVE-2026-48782 used IPv6 transition forms, but only when an application explicitly applied force_download='allow-local' to attacker-influenced input. Bundled adapters did not propagate that option, and some forms also required NAT64 or ISATAP routing. Fixes arrived in 1.99.0, 1.102.0, and 2.0.0b3.
  • The advisories establish exploitability, not observed abuse. There is currently no public evidence that these attack paths have been used in actual attacks.

Applicable AIDEFEND Defenses (4)

AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
Very High
Reconcile the Pydantic AI version running in every application with all three advisories, rebuild on the current supported release, stage deployment, and read back the fleet to prove older packages and images have exited. This avoids stopping at 1.56.0 while later transition-address bypasses remain in scope.
AID-H-019.001
URL Normalization & Allowlist Filtering
Very High
Before the server fetches any message-history URL, canonicalize it, resolve and pin the destination, reject private, loopback, link-local, metadata, and IPv6-transition ranges, validate every redirect, and return bytes from that same verified connection. This is the direct control for the original SSRF and its parser-versus-network bypasses.
AID-I-002.002
Secure External AI Service Connectivity
High
Apply default-deny egress to the application workload and allow only approved external services through verified DNS and SNI policy, with cloud metadata explicitly blocked. This provides a network backstop if application validation is bypassed, although it cannot decide whether an allowed public URL is safe for the business context.
AID-H-002.002
Inference-Time Prompt & Input Validation
Medium
Validate the untrusted message-history schema at ingress, allow only required URL-part types, reject unknown fields, and prevent callers from setting force_download or an equivalent local-fetch override. This removes unsafe authority from the serialized request, but a syntactically valid URL still needs the dedicated safe-fetch checks in AID-H-019.001.

What Defenders Should Do Now

  • Upgrade pydantic-ai and pydantic-ai-slim to the current supported release across every web, AG-UI, Vercel AI, and custom adapter deployment. Verify the effective package and image digest, not only a lockfile change.
  • Find every API that accepts serialized message history or URL-backed media and documents. Reject caller-controlled force_download, allow-local, or equivalent policy overrides.
  • Test safe fetch with loopback, RFC1918, link-local metadata, IPv4-mapped IPv6, 6to4, NAT64, ISATAP, DNS rebinding, and redirect chains. Confirm the address checked is the address actually contacted.
  • Apply workload-level default-deny egress and explicitly block cloud metadata routes. Permit only the external hosts the application needs, through a controlled proxy where practical.
  • Review outbound and metadata-service logs for suspicious requests. Rotate a credential only when evidence shows that specific secret was returned or exposed; SSRF potential alone is not proof of credential loss.

Conclusion

The important boundary is not “chat text versus file upload.” It is whether untrusted conversation data can make the server perform I/O under its own network authority. AIDEFEND  maps this path to supported-version remediation, strict message schemas, SSRF-safe URL handling, and independently enforced egress. Treat replayable history as active input whenever restoring it can fetch, open, execute, or otherwise act.