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.
ASSESSED SYSTEM
A vulnerable Pydantic AI application that accepted attacker-controlled serialized message history or URL-backed attachments and allowed the application server to download those URLs.
OUT OF SCOPE
Applications using only developer-controlled URLs, patched versions, and the later IPv6-transition paths unless allow-local downloads were explicitly enabled.
Architecture: Tool-Calling LLM / Connected GenAI (decision tree Q3) — Replaying model message history invoked server-side download I/O, but the source does not establish autonomous multi-step planning beyond the connected fetch capability. Tier 1: Tier 1 because the server-side fetch authority could reach private services or cloud metadata with application-network privileges.
Documented attack or failure path
- 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.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- The vulnerable condition required attacker-controlled history or URL fields; hardcoded or developer-controlled URLs were not affected by the original path.
- Fixed releases added scheme, address, DNS, and redirect checks, giving a deterministic software-remediation path.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.09–0.74 (midpoint 0.41), Tier 1 MVT 0.60 indeterminate | |||
| Ro-1Adversarial Input Resistance | 0.25w 0.35 | The 0.25 anchor: structured input was accepted with insufficient scheme, address, DNS, and redirect validation in affected versions. | A crafted message-history object or URL-backed attachment reached download_item(), which fetched an attacker-selected address with server-side network access.source: primary/brief |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 1 MVT 0.60 indeterminate | |||
| Transparency (Tr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 1 MVT 0.55 indeterminate | |||
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 1 MVT 0.60 indeterminate | |||
| Containment (Cn) — scenario interval 0.09–0.73 (midpoint 0.41), Tier 1 MVT 0.65 indeterminate | |||
| Cn-1Scope Enforcement | 0.25w 0.16 | The 0.25 anchor: the application boundary existed but did not enforce a deterministic destination scope for the connected fetch capability. | The external caller could direct the application server toward localhost, private services, link-local cloud metadata, or other destinations unavailable from the Internet.source: primary/brief |
| Cn-3Output Filtering Robustness | 0.25w 0.20 | The 0.25 anchor: common typed message handling existed, but an adaptive structured input could be laundered into an unsafe tool-side effect. | Serialized history was treated as passive conversation data even though replaying it activated URL downloads before a fail-closed network-destination gate.source: primary/brief |
Unknown, not N/A: 20 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.35 | Placed from the demonstrated decision and action authority of the assessed boundary; public evidence supports this bounded level but not a broader claim about current product defaults. |
| AsAttack Surface Exposure | 1.00w 0.25 | Placed from who can supply the initiating content or protocol message and from the trust status of that source in the documented configuration. elevated |
| CpCascade Potential | 1.00w 0.25 | No verified System Dependency Graph with DGC at least 0.90 is public for this boundary, so the specification's worst-case graph default governs rather than an assessor-estimated blast radius.GDCP: worst-case default — no verified dependency graph published elevated |
| RfRemediation Feasibility | 0.00w 0.15 | Placed from the documented remediation class: deterministic package/configuration change where available, otherwise provider, architecture, or multi-layer changes. It does not assert fleet-wide closure. |
Nelevated = 2 (dimensions strictly above 0.75) → CRM = 1.15.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.35 | The public record identifies the affected product or representative configuration, attack path, and principal control boundaries, but does not provide a complete asset manifest, verified dependency graph, configuration export, or assessment evidence manifest. |
| Ec — Public evaluation coverage | 0.12 | coverage 0.13 (3 of 23 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.01 | Evidence dated 2026-02-06; age 188 days on the workpaper reference date. Components: T_calendar 0.01 · C_monitor 0.65 · C_event 0.65 · C_evidence 0.85. Binding term: T_calendar. Evidence age is measured from 2026-02-06 to the 2026-08-13 workpaper reference date. Public sources do not provide a passing containment or behavioral re-attestation receipt; event, monitoring, and unresolved-evidence caps remain diagnostic only. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.08 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-003.010 | Deployed AI Software Vulnerability Remediation LifecycleAIDEFEND dataVersion 2026.08.05. 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. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | Very High | Ro-4 Tr-4 |
| AID-H-019.001 | URL Normalization & Allowlist FilteringAIDEFEND dataVersion 2026.08.05. 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. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | Very High | Cn-1 Cn-3 Ro-1 |
| AID-I-002.002 | Secure External AI Service ConnectivityAIDEFEND dataVersion 2026.08.05. 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. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | High | Cn-4 |
| AID-H-002.002 | Inference-Time Prompt & Input ValidationAIDEFEND dataVersion 2026.08.05. 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. This relationship is an evidence route only and supplies no positive score credit without observed control operation. | Medium | Fa-1 Fa-3 Ro-1 |
WHAT THIS CASE TEACHES
Serialized conversation history is active authority when deserialization triggers I/O; replay paths require the same destination policy as an explicit network tool call.
Sources: AIDEFEND in Action — Pydantic AI Shows How Message History Can Become Server-Side Fetch Authority · Primary source — Server-Side Request Forgery (SSRF) in URL Download Handling