Every CVE Search/ Get API key

CVE-2026-48782

pydantic-ai: SSRF blocklist bypass via IPv4-compatible, SIIT/IVI, and local NAT64 IPv6 addresses (incomplete fix of CVE-2026-46678)

6.8 MediumFix available

Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. In versions 1.56.0 through 1.101.0, 2.0.0b1, and 2.0.0b2, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix, CVE-2026-46678, did not decode, exposing cloud IAM short-term credentials. The previous remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix, so the metadata guarantee did not hold for the remaining transition forms: IPv4-compatible IPv6 (::a.b.c.d), the NAT64 RFC 8215 local-use prefix (64:ff9b:1::/48), operator-chosen NAT64 prefixes, and ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint. This occurs 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 actually routes the affected IPv6 transition 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 these forms 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 / CVE-2026-46678 (itself a follow-up to CVE-2026-25580). This issue has been fixed in version 2.0.0b3.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
High
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
None
Availability
None

Exploit likelihood

0.40%Up 0.4 points since Jun 12, 2026
90%50%10%1%

What each source reports

CVE List Score used 6.8

pydantic-ai: SSRF blocklist bypass via IPv4-compatible, SIIT/IVI, and local NAT64 IPv6 addresses (incomplete fix of CVE-2026-46678)

Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. In versions 1.56.0 through 1.101.0, 2.0.0b1, and 2.0.0b2, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix, CVE-2026-46678, did not decode, exposing cloud IAM short-term credentials. The previous remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix, so the metadata guarantee did not hold for the remaining transition forms: IPv4-compatible IPv6 (::a.b.c.d), the NAT64 RFC 8215 local-use prefix (64:ff9b:1::/48), operator-chosen NAT64 prefixes, and ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint. This occurs 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 actually routes the affected IPv6 transition 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 these forms 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 / CVE-2026-46678 (itself a follow-up to CVE-2026-25580). This issue has been fixed in version 2.0.0b3.

Record
CVE-2026-48782
CVSS 3.1
6.8 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Weakness
CWE-918
Updated
2026-11-02
EUVDEUVD-2026-37512 6.8

Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. In versions 1.56.0 through 1.101.0, 2.0.0b1, and 2.0.0b2, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix, CVE-2026-46678, did not decode, exposing cloud IAM short-term credentials. The previous remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix, so the metadata guarantee did not hold for the remaining transition forms: IPv4-compatible IPv6 (::a.b.c.d), the NAT64 RFC 8215 local-use prefix (64:ff9b:1::/48), operator-chosen NAT64 prefixes, and ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint. This occurs 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 actually routes the affected IPv6 transition 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 these forms 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 / CVE-2026-46678 (itself a follow-up to CVE-2026-25580). This issue has been fixed in version 2.0.0b3.

Record
EUVD-2026-37512
CVSS 3.1
6.8 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-cg7w-rg45-pc59 6.8

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 / CVE-2026-46678 (itself a follow-up to 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…

Record
GHSA-cg7w-rg45-pc59
CVSS 3.1
6.8 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Weakness
CWE-918
Updated
2026-11-02
NVD 6.8

Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. In versions 1.56.0 through 1.101.0, 2.0.0b1, and 2.0.0b2, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix, CVE-2026-46678, did not decode, exposing cloud IAM short-term credentials. The previous remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix, so the metadata guarantee did not hold for the remaining transition forms: IPv4-compatible IPv6 (::a.b.c.d), the NAT64 RFC 8215 local-use prefix (64:ff9b:1::/48), operator-chosen NAT64 prefixes, and ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint. This occurs 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 actually routes the affected IPv6 transition 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 these forms 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 / CVE-2026-46678 (itself a follow-up to CVE-2026-25580). This issue has been fixed in version 2.0.0b3.

Record
CVE-2026-48782
CVSS 3.1
6.8 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Weakness
CWE-918
Updated
2026-11-02
OSV 6.8

pydantic-ai: SSRF blocklist bypass via IPv4-compatible, SIIT/IVI, and local NAT64 IPv6 addresses (incomplete fix of CVE-2026-46678)

Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. In versions 1.56.0 through 1.101.0, 2.0.0b1, and 2.0.0b2, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix, CVE-2026-46678, did not decode, exposing cloud IAM short-term credentials. The previous remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix, so the metadata guarantee did not hold for the remaining transition forms: IPv4-compatible IPv6 (::a.b.c.d), the NAT64 RFC 8215 local-use prefix (64:ff9b:1::/48), operator-chosen NAT64 prefixes, and ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint. This occurs 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 actually routes the affected IPv6 transition 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 these forms 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 / CVE-2026-46678 (itself a follow-up to CVE-2026-25580). This issue has been fixed in version 2.0.0b3.

Record
CVE-2026-48782
CVSS 3.1
6.8 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Weakness
CWE-918
Updated
2026-11-02
OSVGHSA-cg7w-rg45-pc59 6.8

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 / CVE-2026-46678 (itself a follow-up to 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…

Record
GHSA-cg7w-rg45-pc59
CVSS 3.1
6.8 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Weakness
CWE-918
Updated
2026-11-02
OSVPYSEC-2026-2977 6.8

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 / CVE-2026-46678 (itself a follow-up to 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…

Record
PYSEC-2026-2977
CVSS 3.1
6.8 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Updated
2026-11-02
OSVPYSEC-2026-2981 6.8

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 / CVE-2026-46678 (itself a follow-up to 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…

Record
PYSEC-2026-2981
CVSS 3.1
6.8 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
Updated
2026-11-02
OSVROOT-APP-PYPI-CVE-2026-48782 No score

CVE-2026-48782 in pydantic-ai-slim - Patched by Root

Root has patched CVE-2026-48782 in the pydantic-ai-slim package for Root:PyPI. Multiple fixed versions available.

Record
ROOT-APP-PYPI-CVE-2026-48782
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
pydantic-ai-slim
PyPI
1.56.0 up to 1.102.0
1.102.0
pydantic-ai
PyPI
1.56.0 up to 1.102.0
1.102.0
pydantic-ai
PyPI
2.0.0b1 up to 2.0.0b3
2.0.0b3
pydantic-ai-slim
PyPI
2.0.0b1 up to 2.0.0b3
2.0.0b3
pydantic-ai-slim
PyPI
1.56.0 up to 1.102.0, plus listed versions
1.100.01.101.01.57.01.58.01.59.0
Show 45 moreShow less
1.60.01.61.01.62.01.63.01.64.01.65.01.66.01.67.01.68.01.69.01.70.01.71.01.72.01.73.01.74.01.75.01.76.01.77.01.78.01.79.01.80.01.81.01.82.01.83.01.84.01.84.11.85.01.85.11.86.01.86.11.87.01.88.01.89.01.89.11.90.01.91.01.92.01.93.01.94.01.95.01.95.11.96.01.96.11.97.01.98.0
1.102.0
pydantic-ai
PyPI
1.56.0 up to 1.102.0, plus listed versions
1.100.01.101.01.57.01.58.01.59.0
Show 45 moreShow less
1.60.01.61.01.62.01.63.01.64.01.65.01.66.01.67.01.68.01.69.01.70.01.71.01.72.01.73.01.74.01.75.01.76.01.77.01.78.01.79.01.80.01.81.01.82.01.83.01.84.01.84.11.85.01.85.11.86.01.86.11.87.01.88.01.89.01.89.11.90.01.91.01.92.01.93.01.94.01.95.01.95.11.96.01.96.11.97.01.98.0
1.102.0
pydantic-ai
PyPI
2.0.0b1 up to 2.0.0b3, plus listed versions
2.0.0b2
2.0.0b3
pydantic-ai-slim
PyPI
2.0.0b1 up to 2.0.0b3, plus listed versions
2.0.0b2
2.0.0b3
pydantic-ai
PyPI
1.56.0 up to 1.102.0, 2.0.0b1 up to 2.0.0b3, plus listed versions
1.100.01.101.01.57.01.58.01.59.0
Show 45 moreShow less
1.60.01.61.01.62.01.63.01.64.01.65.01.66.01.67.01.68.01.69.01.70.01.71.01.72.01.73.01.74.01.75.01.76.01.77.01.78.01.79.01.80.01.81.01.82.01.83.01.84.01.84.11.85.01.85.11.86.01.86.11.87.01.88.01.89.01.89.11.90.01.91.01.92.01.93.01.94.01.95.01.95.11.96.01.96.11.97.01.98.0
1.102.02.0.0b3
pydantic-ai-slim
PyPI
1.56.0 up to 1.102.0, 2.0.0b1 up to 2.0.0b3, plus listed versions
1.100.01.101.01.57.01.58.01.59.0
Show 45 moreShow less
1.60.01.61.01.62.01.63.01.64.01.65.01.66.01.67.01.68.01.69.01.70.01.71.01.72.01.73.01.74.01.75.01.76.01.77.01.78.01.79.01.80.01.81.01.82.01.83.01.84.01.84.11.85.01.85.11.86.01.86.11.87.01.88.01.89.01.89.11.90.01.91.01.92.01.93.01.94.01.95.01.95.11.96.01.96.11.97.01.98.0
1.102.02.0.0b3
pydantic-ai-slim
Root:PyPI
before 1.84.0+aikido.2
1.84.0+aikido.21.88.0+aikido.21.84.1+aikido.21.91.0+aikido.2

History

History
RecordedChangedSources
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-48782 is a medium vulnerability (CVSS 6.8) in Pydantic Pydantic-ai, published June 16, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.40%, the 34th percentile. Fixed in pydantic-ai-slim 1.102.0.

References

Show 4 moreShow less
This page doesn't list everything

Left out here: 6 versions and the rest of 4 source descriptions. The JSON record has them.

MoveEnter Open