8 known bugs in pydantic-ai-slim, with affected versions, fixes and workarounds. Sourced from upstream issue trackers.
| Severity | Affected | Fixed in | Title | Status | Source |
|---|
| high | 1.34.0 | 1.51.0 | Pydantic AI has Stored XSS via Path Traversal in Web UI CDN URL ## Summary
A Path Traversal vulnerability in the [Pydantic AI web UI](https://ai.pydantic.dev/web/) allows an attacker to serve arbitrary JavaScript in the context of the application by crafting a malicious URL. If a victim clicks the link or visits it via an iframe, attacker-controlled code executes in their browser, enabling theft of chat history and other client-side data.
**This vulnerability only affects applications that use:**
- **`Agent.to_web`** to serve a chat interface
- **`clai web`** to serve a chat interface from the CLI
These are typically run locally (on `localhost`), but may also be deployed on a remote server.
### Description
The web UI serves its frontend HTML by fetching it from a CDN. In affected versions, the CDN URL is constructed using a `version` query parameter from the request URL. This parameter is not validated, allowing path traversal sequences that cause the server to fetch and serve attacker-controlled HTML/JavaScript from an arbitrary source on the same CDN, instead of the legitimate chat UI package.
### Who Is Affected
Projects are affected if your application uses `Agent.to_web` or `clai web` to serve the Pydantic AI chat interface.
### Attack Scenario
1. An attacker crafts a URL pointing to the victim's Pydantic AI web UI instance (either `localhost` with the known port, or a remote server endpoint) with a malicious `version` query parameter containing path traversal sequences.
2. The attacker gets the victim to visit this URL — directly via a link, through a redirect, or by embedding it in an iframe.
3. When the victim's browser loads the page, the server fetches and serves attacker-controlled HTML/JavaScript instead of the legitimate chat UI.
4. The attacker's JavaScript executes in the victim's browser in the context of the Pydantic AI web application, with access to:
- **Chat history** stored in `localStorage` (all user messages and AI responses)
- **Session cookies** that are not set as `HttpOnly`, if authentication middleware is configured
## Remediation
### Upgrade to Patched Version
**Upgrade** to the patched version or later. The fix removes the user-controllable `version` parameter entirely. The CDN URL is now hardcoded at startup and cannot be influenced by request parameters.
A new `html_source` parameter is available on `Agent.to_web` and `create_web_app` for applications that need to customize the UI source (e.g., for enterprise environments, offline usage, or custom UI builds). This parameter is only settable in application code, not via query parameters. | fixed | osv:GHSA-wjp5-868j-wqv7 |
| high | 0.0.26 | 1.56.0 | Pydantic AI has Server-Side Request Forgery (SSRF) in URL Download Handling ## Summary
A Server-Side Request Forgery (SSRF) vulnerability exists in Pydantic AI's URL download functionality. When applications accept message history from untrusted sources, attackers can include malicious URLs that cause the server to make HTTP requests to internal network resources, potentially accessing internal services or cloud credentials.
**This vulnerability only affects applications that accept message history from external users**, such as those using:
- **`Agent.to_web`** or **`clai web`** to serve a chat interface
- **`VercelAIAdapter`** for Vercel AI SDK integration
- **`AGUIAdapter`** or **`Agent.to_ag_ui`** for AG-UI protocol integration
- Custom APIs that accept message history from user input
Applications that only use hardcoded or developer-controlled URLs are not affected.
### Description
The `download_item()` helper function downloads content from URLs without validating that the target is a public internet address. When user-supplied message history contains URLs, attackers can:
1. **Access internal services**: Request `http://127.0.0.1`, `localhost`, or private IP ranges (`10.x.x.x`, `172.16.x.x`, `192.168.x.x`)
2. **Steal cloud credentials**: Access cloud metadata endpoints (AWS IMDSv1 at `169.254.169.254`, GCP, Azure, Alibaba Cloud)
3. **Scan internal networks**: Enumerate internal hosts and ports
### Who Is Affected
You are affected if your application:
1. **Uses `Agent.to_web` or `clai web`** - The web interface accepts file attachments via the Vercel AI Data Stream Protocol, where users can provide arbitrary URLs through chat messages.
2. **Uses `VercelAIAdapter`** - Chat interfaces built with Vercel AI SDK allow users to submit messages containing URLs that are processed server-side.
3. **Uses `AGUIAdapter` or `Agent.to_ag_ui`** - The AG-UI protocol allows users to provide file references with URLs as part of agent interactions.
4. **Exposes a custom API accepting message history** - Any endpoint that accepts message history or `ImageUrl`, `AudioUrl`, `VideoUrl`, `DocumentUrl` objects from user input.
### Attack Scenario
Via chat interface, an attacker submits a message with a file attachment pointing to an internal resource:
```json
{
"role": "user",
"parts": [
{"type": "file", "mediaType": "image/png", "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
]
}
```
### Affected Model Integrations
Multiple model integrations download URL content in certain conditions:
| Provider | Downloaded Types |
|----------|------------------|
| `OpenAIChatModel` | `AudioUrl`, `DocumentUrl` |
| `AnthropicModel` | `DocumentUrl` (`text/plain`) |
| `GoogleModel` (GLA) | All URL types (except YouTube and Files API URLs) |
| `XaiModel` | `DocumentUrl` |
| `BedrockConverseModel` | `ImageUrl`, `DocumentUrl`, `VideoUrl` (non-S3 URLs) |
| `OpenRouterModel` | `AudioUrl` |
## Remediation
### Upgrade to Patched Version
**Upgrade** to the patched version or later. The fix adds comprehensive SSRF protection:
- Blocks private/internal IP addresses by default
- Always blocks cloud metadata endpoints (even with `allow-local`)
- Only allows `http://` and `https://` protocols
- Resolves hostnames before requests to prevent DNS rebinding
- Validates each redirect target
### New `force_download='allow-local'` Option
If an application legitimately needs to access local/private network resources (e.g., in a fully trusted internal environment), it can explicitly opt in:
```python
from pydantic_ai import ImageUrl
# Default behavior: private IPs are blocked
ImageUrl(url="http://internal-service/image.png") # Raises ValueError
# Opt-in to allow local access (use with caution)
ImageUrl(url="http://internal-service/image.png", force_download='allow-local')
```
**Important**: Cloud metadata endpoints (`169.254.169.254`, `fd00:ec2::254`, `100.100.100.200`) are **always blocked**, even with `allow-local`.
### Workaround for Older Versions
If a project cannot upgrade immediately, use a [history processor](https://ai.pydantic.dev/message-history/#processing-message-history) to filter out URLs targeting local/private addresses:
```python
import ipaddress
import socket
from urllib.parse import urlparse
from pydantic_ai import Agent, ModelMessage, ModelRequest
from pydantic_ai.messages import AudioUrl, DocumentUrl, ImageUrl, VideoUrl
def is_private_url(url: str) -> bool:
"""Check if a URL targets a private/internal IP address."""
try:
parsed = urlparse(url)
hostname = parsed.hostname
if not hostname:
return True # Invalid URL, block it
# Resolve hostname to IP
ip_str = socket.gethostbyname(hostname)
ip = ipaddress.ip_address(ip_str)
# Block private, loopback, and link-local addresses
return ip.is_private or ip.is_loopback or ip.is_link_local
except (socket.gaierror, ValueError):
return True # DNS resolution failed, block it
def filter_private_urls(messages: list[ModelMessage]) -> list[ModelMessage]:
"""Remove URL parts that target private/internal addresses."""
url_types = (ImageUrl, AudioUrl, VideoUrl, DocumentUrl)
filtered = []
for msg in messages:
if isinstance(msg, ModelRequest):
safe_parts = [
part for part in msg.parts
if not (isinstance(part, url_types) and is_private_url(part.url))
]
if safe_parts:
filtered.append(ModelRequest(parts=safe_parts))
else:
filtered.append(msg)
return filtered
# Apply the filter to your agent
agent = Agent('openai:gpt-5', history_processors=[filter_private_urls])
```
## Technical Details of the Fix
The fix introduces a new `_ssrf.py` module with comprehensive protection:
1. **Protocol validation**: Only `http://` and `https://` allowed
2. **DNS resolution before request**: Prevents DNS rebinding attacks
3. **Private IP blocking** (by default):
- `127.0.0.0/8`, `::1/128` (loopback)
- `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` (private)
- `169.254.0.0/16`, `fe80::/10` (link-local)
- `100.64.0.0/10` (CGNAT)
- `fc00::/7` (unique local)
- `2002::/16` (6to4, can embed private IPv4)
4. **Cloud metadata always blocked**: `169.254.169.254`, `fd00:ec2::254`, `100.100.100.200`
5. **Safe redirect handling**: Each redirect validated before following (max 10) | ||
| medium | 1.34.0 | 1.51.0 | Pydantic AI has Stored XSS via Path Traversal in Web UI CDN URL ## Summary
A Path Traversal vulnerability in the [Pydantic AI web UI](https://ai.pydantic.dev/web/) allows an attacker to serve arbitrary JavaScript in the context of the application by crafting a malicious URL. If a victim clicks the link or visits it via an iframe, attacker-controlled code executes in their browser, enabling theft of chat history and other client-side data.
**This vulnerability only affects applications that use:**
- **`Agent.to_web`** to serve a chat interface
- **`clai web`** to serve a chat interface from the CLI
These are typically run locally (on `localhost`), but may also be deployed on a remote server.
### Description
The web UI serves its frontend HTML by fetching it from a CDN. In affected versions, the CDN URL is constructed using a `version` query parameter from the request URL. This parameter is not validated, allowing path traversal sequences that cause the server to fetch and serve attacker-controlled HTML/JavaScript from an arbitrary source on the same CDN, instead of the legitimate chat UI package.
### Who Is Affected
Projects are affected if your application uses `Agent.to_web` or `clai web` to serve the Pydantic AI chat interface.
### Attack Scenario
1. An attacker crafts a URL pointing to the victim's Pydantic AI web UI instance (either `localhost` with the known port, or a remote server endpoint) with a malicious `version` query parameter containing path traversal sequences.
2. The attacker gets the victim to visit this URL — directly via a link, through a redirect, or by embedding it in an iframe.
3. When the victim's browser loads the page, the server fetches and serves attacker-controlled HTML/JavaScript instead of the legitimate chat UI.
4. The attacker's JavaScript executes in the victim's browser in the context of the Pydantic AI web application, with access to:
- **Chat history** stored in `localStorage` (all user messages and AI responses)
- **Session cookies** that are not set as `HttpOnly`, if authentication middleware is configured
## Remediation
### Upgrade to Patched Version
**Upgrade** to the patched version or later. The fix removes the user-controllable `version` parameter entirely. The CDN URL is now hardcoded at startup and cannot be influenced by request parameters.
A new `html_source` parameter is available on `Agent.to_web` and `create_web_app` for applications that need to customize the UI source (e.g., for enterprise environments, offline usage, or custom UI builds). This parameter is only settable in application code, not via query parameters. | ||
| medium | 1.56.0 | 1.99.0 | Pydantic AI: SSRF cloud-metadata blocklist bypass via IPv4-mapped IPv6 (Incomplete fix of CVE-2026-25580) ## Summary
When an application using Pydantic AI opts a URL into `force_download='allow-local'` (which disables the default block on private/internal IPs), the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form (IPv4-mapped IPv6, 6to4, or NAT64). Dual-stack and translated networks route the IPv6 wrapper to the underlying IPv4 endpoint, exposing cloud IAM short-term credentials.
This is an incomplete fix of [GHSA-2jrp-274c-jhv3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-2jrp-274c-jhv3) / [CVE-2026-25580](https://nvd.nist.gov/vuln/detail/CVE-2026-25580). The parent advisory's remediation guaranteed that "cloud metadata endpoints are always blocked, even with `allow-local`." That guarantee did not hold for IPv6-encoded forms of the metadata IPs.
## Severity
Same impact metrics as the parent CVE, but materially narrower attack surface (AC:H instead of AC:L), because exploitation requires the application to have opted into `allow-local` on a URL influenced by untrusted input.
## Who Is Affected
Applications are affected **only if** they explicitly opt for `FileUrl` (`ImageUrl`, `AudioUrl`, `VideoUrl`, `DocumentUrl`) into `force_download='allow-local'` on a URL that is, or could be, influenced by untrusted input.
Applications are **not** affected if they use any of the bundled integrations to ingest user input, because they do not propagate `force_download` from external data:
- `Agent.to_web` / `clai web`
- `VercelAIAdapter`
- `AGUIAdapter` / `Agent.to_ag_ui`
Applications that only download from developer-controlled URLs are not affected.
## Remediation
Upgrade to `1.99.0` or later. The cloud-metadata and private-IP blocklists now apply to IPv6 transition forms that route to a blocked IPv4 endpoint (IPv4-mapped IPv6, 6to4, and NAT64 well-known prefix). The blocklists have also been extended to cover additional IANA-reserved IPv4 and IPv6 special-purpose ranges.
## Workaround for Unpatched Versions
Avoid passing `force_download='allow-local'` on any URL that could be influenced by untrusted input. If developers must, resolve the hostname themselves and validate the result against their own metadata blocklist — including IPv6-encoded forms — before constructing the `FileUrl`.
## Credits
Reported by [j0hndo](mailto:[email protected]). | ||
| medium | 2.0.0b1 | 2.0.0b3 | pydantic-ai: SSRF blocklist bypass via IPv4-compatible, SIIT/IVI, and local NAT64 IPv6 addresses (incomplete fix of CVE-2026-46678) ## Summary
When an application using Pydantic AI opts a URL into `force_download='allow-local'` (which disables the default block on private/internal IPs) **and runs on a network that routes the affected IPv6 transition forms (NAT64- or ISATAP-configured networks)**, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix did not decode — IPv4-compatible IPv6 (`::a.b.c.d`), the NAT64 RFC 8215 local-use prefix (`64:ff9b:1::/48`), operator-chosen NAT64 prefixes, or ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint, exposing cloud IAM short-term credentials.
**The bypass is exploitable only in environments whose network actually routes these forms** — NAT64-configured networks (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or networks with an ISATAP tunnel for ISATAP. A standard dual-stack cloud VM or container does not route them and is not affected in practice. The IPv4-compatible and Teredo variants are deprecated and addressed as defense-in-depth.
This is an incomplete fix of [GHSA-cqp8-fcvh-x7r3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-cqp8-fcvh-x7r3) / [CVE-2026-46678](https://nvd.nist.gov/vuln/detail/CVE-2026-46678) (itself a follow-up to [CVE-2026-25580](https://nvd.nist.gov/vuln/detail/CVE-2026-25580)). The prior remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix; the metadata guarantee did not hold for the remaining transition forms.
## Severity
**MEDIUM** — `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N` = **6.8**
Same impact metrics and narrow attack surface as the parent advisory (AC:H): exploitation requires the application to have opted into `allow-local` on a URL influenced by untrusted input, and the NAT64/ISATAP variants additionally require the deployment network to route those forms.
**CWE-918**: Server-Side Request Forgery (SSRF)
## Affected Versions
| Package | Vulnerable | Patched |
|---|---|---|
| `pydantic-ai` | `>= 1.56.0, < 1.102.0`; `>= 2.0.0b1, < 2.0.0b3` | `1.102.0`; `2.0.0b3` |
| `pydantic-ai-slim` | `>= 1.56.0, < 1.102.0`; `>= 2.0.0b1, < 2.0.0b3` | `1.102.0`; `2.0.0b3` |
These transition forms have not been decoded since SSRF protection was introduced in `1.56.0`.
## Who Is Affected
Users are affected **only if** their application explicitly opts a `FileUrl` (`ImageUrl`, `AudioUrl`, `VideoUrl`, `DocumentUrl`) into `force_download='allow-local'` on a URL that is, or could be, influenced by untrusted input.
Beyond that precondition, the affected encodings only reach a metadata endpoint in environments whose network actually routes them. The broadly-routable IPv4-mapped form was addressed in `1.99.0` (CVE-2026-46678); the additional forms addressed here require a **NAT64-configured network** (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or an **ISATAP tunnel** for the ISATAP variant. The IPv4-compatible and Teredo forms are deprecated and not routed by modern stacks; they are addressed as defense-in-depth. Most deployments on a standard dual-stack cloud VM or container are therefore not exploitable in practice, but the fix restores the "always blocked" guarantee for the environments that are.
Users are **not** affected if they use any of the bundled integrations to ingest user input, because they do not propagate `force_download` from external data:
- `Agent.to_web` / `clai web`
- `VercelAIAdapter`
- `AGUIAdapter` / `Agent.to_ag_ui`
Applications that only download from developer-controlled URLs are not affected.
## Remediation
Upgrade to `1.102.0` or later (or `2.0.0b3` or later on the 2.0 pre-release line). The cloud-metadata and private-IP blocklists now decode the embedded IPv4 of every standardized IPv6 transition form before evaluating it — IPv4-mapped, IPv4-compatible, 6to4, NAT64 across all prefix lengths (including the RFC 8215 local-use prefix and operator-chosen prefixes), ISATAP, and Teredo. The set of always-blocked cloud metadata/credential endpoints has also been expanded across providers.
## Workaround for Unpatched Versions
Avoid passing `force_download='allow-local'` on any URL that could be influenced by untrusted input. If developers must, resolve the hostname themselves and validate the result against their own metadata blocklist — including IPv6 transition forms — before constructing the `FileUrl`.
## Credits
Reported by [@SnailSploit](https://snailsploit.com). | ||
| medium | 0.0.26 | 1.56.0 | Pydantic AI has Server-Side Request Forgery (SSRF) in URL Download Handling ## Summary
A Server-Side Request Forgery (SSRF) vulnerability exists in Pydantic AI's URL download functionality. When applications accept message history from untrusted sources, attackers can include malicious URLs that cause the server to make HTTP requests to internal network resources, potentially accessing internal services or cloud credentials.
**This vulnerability only affects applications that accept message history from external users**, such as those using:
- **`Agent.to_web`** or **`clai web`** to serve a chat interface
- **`VercelAIAdapter`** for Vercel AI SDK integration
- **`AGUIAdapter`** or **`Agent.to_ag_ui`** for AG-UI protocol integration
- Custom APIs that accept message history from user input
Applications that only use hardcoded or developer-controlled URLs are not affected.
### Description
The `download_item()` helper function downloads content from URLs without validating that the target is a public internet address. When user-supplied message history contains URLs, attackers can:
1. **Access internal services**: Request `http://127.0.0.1`, `localhost`, or private IP ranges (`10.x.x.x`, `172.16.x.x`, `192.168.x.x`)
2. **Steal cloud credentials**: Access cloud metadata endpoints (AWS IMDSv1 at `169.254.169.254`, GCP, Azure, Alibaba Cloud)
3. **Scan internal networks**: Enumerate internal hosts and ports
### Who Is Affected
You are affected if your application:
1. **Uses `Agent.to_web` or `clai web`** - The web interface accepts file attachments via the Vercel AI Data Stream Protocol, where users can provide arbitrary URLs through chat messages.
2. **Uses `VercelAIAdapter`** - Chat interfaces built with Vercel AI SDK allow users to submit messages containing URLs that are processed server-side.
3. **Uses `AGUIAdapter` or `Agent.to_ag_ui`** - The AG-UI protocol allows users to provide file references with URLs as part of agent interactions.
4. **Exposes a custom API accepting message history** - Any endpoint that accepts message history or `ImageUrl`, `AudioUrl`, `VideoUrl`, `DocumentUrl` objects from user input.
### Attack Scenario
Via chat interface, an attacker submits a message with a file attachment pointing to an internal resource:
```json
{
"role": "user",
"parts": [
{"type": "file", "mediaType": "image/png", "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
]
}
```
### Affected Model Integrations
Multiple model integrations download URL content in certain conditions:
| Provider | Downloaded Types |
|----------|------------------|
| `OpenAIChatModel` | `AudioUrl`, `DocumentUrl` |
| `AnthropicModel` | `DocumentUrl` (`text/plain`) |
| `GoogleModel` (GLA) | All URL types (except YouTube and Files API URLs) |
| `XaiModel` | `DocumentUrl` |
| `BedrockConverseModel` | `ImageUrl`, `DocumentUrl`, `VideoUrl` (non-S3 URLs) |
| `OpenRouterModel` | `AudioUrl` |
## Remediation
### Upgrade to Patched Version
**Upgrade** to the patched version or later. The fix adds comprehensive SSRF protection:
- Blocks private/internal IP addresses by default
- Always blocks cloud metadata endpoints (even with `allow-local`)
- Only allows `http://` and `https://` protocols
- Resolves hostnames before requests to prevent DNS rebinding
- Validates each redirect target
### New `force_download='allow-local'` Option
If an application legitimately needs to access local/private network resources (e.g., in a fully trusted internal environment), it can explicitly opt in:
```python
from pydantic_ai import ImageUrl
# Default behavior: private IPs are blocked
ImageUrl(url="http://internal-service/image.png") # Raises ValueError
# Opt-in to allow local access (use with caution)
ImageUrl(url="http://internal-service/image.png", force_download='allow-local')
```
**Important**: Cloud metadata endpoints (`169.254.169.254`, `fd00:ec2::254`, `100.100.100.200`) are **always blocked**, even with `allow-local`.
### Workaround for Older Versions
If a project cannot upgrade immediately, use a [history processor](https://ai.pydantic.dev/message-history/#processing-message-history) to filter out URLs targeting local/private addresses:
```python
import ipaddress
import socket
from urllib.parse import urlparse
from pydantic_ai import Agent, ModelMessage, ModelRequest
from pydantic_ai.messages import AudioUrl, DocumentUrl, ImageUrl, VideoUrl
def is_private_url(url: str) -> bool:
"""Check if a URL targets a private/internal IP address."""
try:
parsed = urlparse(url)
hostname = parsed.hostname
if not hostname:
return True # Invalid URL, block it
# Resolve hostname to IP
ip_str = socket.gethostbyname(hostname)
ip = ipaddress.ip_address(ip_str)
# Block private, loopback, and link-local addresses
return ip.is_private or ip.is_loopback or ip.is_link_local
except (socket.gaierror, ValueError):
return True # DNS resolution failed, block it
def filter_private_urls(messages: list[ModelMessage]) -> list[ModelMessage]:
"""Remove URL parts that target private/internal addresses."""
url_types = (ImageUrl, AudioUrl, VideoUrl, DocumentUrl)
filtered = []
for msg in messages:
if isinstance(msg, ModelRequest):
safe_parts = [
part for part in msg.parts
if not (isinstance(part, url_types) and is_private_url(part.url))
]
if safe_parts:
filtered.append(ModelRequest(parts=safe_parts))
else:
filtered.append(msg)
return filtered
# Apply the filter to your agent
agent = Agent('openai:gpt-5', history_processors=[filter_private_urls])
```
## Technical Details of the Fix
The fix introduces a new `_ssrf.py` module with comprehensive protection:
1. **Protocol validation**: Only `http://` and `https://` allowed
2. **DNS resolution before request**: Prevents DNS rebinding attacks
3. **Private IP blocking** (by default):
- `127.0.0.0/8`, `::1/128` (loopback)
- `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` (private)
- `169.254.0.0/16`, `fe80::/10` (link-local)
- `100.64.0.0/10` (CGNAT)
- `fc00::/7` (unique local)
- `2002::/16` (6to4, can embed private IPv4)
4. **Cloud metadata always blocked**: `169.254.169.254`, `fd00:ec2::254`, `100.100.100.200`
5. **Safe redirect handling**: Each redirect validated before following (max 10) | ||
| medium | 1.56.0 | 1.99.0 | Pydantic AI: SSRF cloud-metadata blocklist bypass via IPv4-mapped IPv6 (Incomplete fix of CVE-2026-25580) ## Summary
When an application using Pydantic AI opts a URL into `force_download='allow-local'` (which disables the default block on private/internal IPs), the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form (IPv4-mapped IPv6, 6to4, or NAT64). Dual-stack and translated networks route the IPv6 wrapper to the underlying IPv4 endpoint, exposing cloud IAM short-term credentials.
This is an incomplete fix of [GHSA-2jrp-274c-jhv3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-2jrp-274c-jhv3) / [CVE-2026-25580](https://nvd.nist.gov/vuln/detail/CVE-2026-25580). The parent advisory's remediation guaranteed that "cloud metadata endpoints are always blocked, even with `allow-local`." That guarantee did not hold for IPv6-encoded forms of the metadata IPs.
## Severity
Same impact metrics as the parent CVE, but materially narrower attack surface (AC:H instead of AC:L), because exploitation requires the application to have opted into `allow-local` on a URL influenced by untrusted input.
## Who Is Affected
Applications are affected **only if** they explicitly opt for `FileUrl` (`ImageUrl`, `AudioUrl`, `VideoUrl`, `DocumentUrl`) into `force_download='allow-local'` on a URL that is, or could be, influenced by untrusted input.
Applications are **not** affected if they use any of the bundled integrations to ingest user input, because they do not propagate `force_download` from external data:
- `Agent.to_web` / `clai web`
- `VercelAIAdapter`
- `AGUIAdapter` / `Agent.to_ag_ui`
Applications that only download from developer-controlled URLs are not affected.
## Remediation
Upgrade to `1.99.0` or later. The cloud-metadata and private-IP blocklists now apply to IPv6 transition forms that route to a blocked IPv4 endpoint (IPv4-mapped IPv6, 6to4, and NAT64 well-known prefix). The blocklists have also been extended to cover additional IANA-reserved IPv4 and IPv6 special-purpose ranges.
## Workaround for Unpatched Versions
Avoid passing `force_download='allow-local'` on any URL that could be influenced by untrusted input. If developers must, resolve the hostname themselves and validate the result against their own metadata blocklist — including IPv6-encoded forms — before constructing the `FileUrl`.
## Credits
Reported by [j0hndo](mailto:[email protected]). | ||
| medium | 1.56.0 | 1.102.0 | pydantic-ai: SSRF blocklist bypass via IPv4-compatible, SIIT/IVI, and local NAT64 IPv6 addresses (incomplete fix of CVE-2026-46678) ## Summary
When an application using Pydantic AI opts a URL into `force_download='allow-local'` (which disables the default block on private/internal IPs) **and runs on a network that routes the affected IPv6 transition forms (NAT64- or ISATAP-configured networks)**, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix did not decode — IPv4-compatible IPv6 (`::a.b.c.d`), the NAT64 RFC 8215 local-use prefix (`64:ff9b:1::/48`), operator-chosen NAT64 prefixes, or ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint, exposing cloud IAM short-term credentials.
**The bypass is exploitable only in environments whose network actually routes these forms** — NAT64-configured networks (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or networks with an ISATAP tunnel for ISATAP. A standard dual-stack cloud VM or container does not route them and is not affected in practice. The IPv4-compatible and Teredo variants are deprecated and addressed as defense-in-depth.
This is an incomplete fix of [GHSA-cqp8-fcvh-x7r3](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-cqp8-fcvh-x7r3) / [CVE-2026-46678](https://nvd.nist.gov/vuln/detail/CVE-2026-46678) (itself a follow-up to [CVE-2026-25580](https://nvd.nist.gov/vuln/detail/CVE-2026-25580)). The prior remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix; the metadata guarantee did not hold for the remaining transition forms.
## Severity
**MEDIUM** — `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N` = **6.8**
Same impact metrics and narrow attack surface as the parent advisory (AC:H): exploitation requires the application to have opted into `allow-local` on a URL influenced by untrusted input, and the NAT64/ISATAP variants additionally require the deployment network to route those forms.
**CWE-918**: Server-Side Request Forgery (SSRF)
## Affected Versions
| Package | Vulnerable | Patched |
|---|---|---|
| `pydantic-ai` | `>= 1.56.0, < 1.102.0`; `>= 2.0.0b1, < 2.0.0b3` | `1.102.0`; `2.0.0b3` |
| `pydantic-ai-slim` | `>= 1.56.0, < 1.102.0`; `>= 2.0.0b1, < 2.0.0b3` | `1.102.0`; `2.0.0b3` |
These transition forms have not been decoded since SSRF protection was introduced in `1.56.0`.
## Who Is Affected
Users are affected **only if** their application explicitly opts a `FileUrl` (`ImageUrl`, `AudioUrl`, `VideoUrl`, `DocumentUrl`) into `force_download='allow-local'` on a URL that is, or could be, influenced by untrusted input.
Beyond that precondition, the affected encodings only reach a metadata endpoint in environments whose network actually routes them. The broadly-routable IPv4-mapped form was addressed in `1.99.0` (CVE-2026-46678); the additional forms addressed here require a **NAT64-configured network** (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or an **ISATAP tunnel** for the ISATAP variant. The IPv4-compatible and Teredo forms are deprecated and not routed by modern stacks; they are addressed as defense-in-depth. Most deployments on a standard dual-stack cloud VM or container are therefore not exploitable in practice, but the fix restores the "always blocked" guarantee for the environments that are.
Users are **not** affected if they use any of the bundled integrations to ingest user input, because they do not propagate `force_download` from external data:
- `Agent.to_web` / `clai web`
- `VercelAIAdapter`
- `AGUIAdapter` / `Agent.to_ag_ui`
Applications that only download from developer-controlled URLs are not affected.
## Remediation
Upgrade to `1.102.0` or later (or `2.0.0b3` or later on the 2.0 pre-release line). The cloud-metadata and private-IP blocklists now decode the embedded IPv4 of every standardized IPv6 transition form before evaluating it — IPv4-mapped, IPv4-compatible, 6to4, NAT64 across all prefix lengths (including the RFC 8215 local-use prefix and operator-chosen prefixes), ISATAP, and Teredo. The set of always-blocked cloud metadata/credential endpoints has also been expanded across providers.
## Workaround for Unpatched Versions
Avoid passing `force_download='allow-local'` on any URL that could be influenced by untrusted input. If developers must, resolve the hostname themselves and validate the result against their own metadata blocklist — including IPv6 transition forms — before constructing the `FileUrl`.
## Credits
Reported by [@SnailSploit](https://snailsploit.com). |
Get this data programmatically \u2014 free, no authentication.
curl https://depscope.dev/api/bugs/pypi/pydantic-ai-slim| fixed |
| osv:GHSA-2jrp-274c-jhv3 |
| fixed |
| osv:PYSEC-2026-2983 |
| fixed |
| osv:PYSEC-2026-2982 |
| fixed |
| osv:PYSEC-2026-2981 |
| fixed |
| osv:PYSEC-2026-2980 |
| fixed |
| osv:GHSA-cqp8-fcvh-x7r3 |
| fixed |
| osv:GHSA-cg7w-rg45-pc59 |