Pydantic AI Harness before 0.59.0 fails to enforce UsageLimits.toolcallslimit on nested tool calls dispatched from runcode in the CodeMode toolset. Users or prompt-injected content can make the sandboxed program invoke tools via runnestedcall() without checkbeforetoolcall, exceeding operator limits on costly or side-effecting tools.

Summary

The Pydantic AI development web chat UI (Agent.toweb(), clai web) did not check the content type of requests to its chat endpoint. This allowed a website visited by a developer to submit a request to a chat UI running on that developer's machine, causing the served agent to run and to execute its tools with the privileges and credentials of the local process.

Binding the web UI to localhost — the default — does not prevent this, because a page open in the developer's browser can reach the loopback address.

Impact

Applications and developers serving an agent through Agent.toweb() or clai web. The consequences depend on the tools the served agent exposes, and can include data disclosure as well as unwanted tool side effects. Tools marked requiresapproval=True were not protected either, because the endpoint trusts approval decisions relayed by the client.

Mitigation

Upgrade to a patched version. The chat endpoint now requires Content-Type: application/json and rejects other requests before the request body is parsed and before the agent runs. The bundled chat UI already sends this header; scripts and other non-browser clients that call the endpoint directly may need to be updated to send it.

If you cannot upgrade, don't run the web UI while browsing untrusted sites, stop it when you aren't using it, and don't serve an agent with side-effecting tools through it.

Credits - Thai Son Dinh from VinSOC Labs (R&D)

Summary

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 (webfetchtool, 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.

Details

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 .

Who Is Affected

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.

Remediation

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.

Credits

Identified during internal review of media-download hardening.

Summary

Pydantic AI's OpenTelemetry instrumentation supports InstrumentationSettings(includecontent=False) to exclude message content — user prompts, model completions, tool call arguments and responses — from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend.

Retry prompts — the feedback messages Pydantic AI sends back to the model when its output fails validation or an output validator raises ModelRetry — were not covered by this setting when they were not associated with a tool call, as with structured output modes that don't use tool calls (e.g. NativeOutput or PromptedOutput) and output validators applied to text output. Their full content was recorded on model request spans even with includecontent=False. Since validation feedback can quote invalid values from the model's response, message content that the setting was configured to withhold could reach the telemetry backend.

Details

Retry prompts without an associated tool call were serialized into span message attributes (such as genai.input.messages and pydanticai.allmessages) as regular text parts, and this path did not apply the includecontent check that every other message part applies. Retry prompts tied to a tool call, and all other message content, were redacted correctly.

Impact

This does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent's own data — a third-party observability vendor or a shared backend — which is the scenario includecontent=False exists for. The disclosed content is limited to retry feedback: validation error details, which can quote invalid values from the model's output, or output-validator ModelRetry messages.

Who Is Affected

You are affected if you enabled instrumentation with includecontent=False and your agent can produce retry prompts outside of tool calls: it uses a structured output mode that doesn't rely on tool calls (such as NativeOutput or PromptedOutput), or output validators on text output. You are not affected if you don't set includecontent=False, or if all of your agent's retries come from tool calls (including the default tool-based structured output mode), which were redacted correctly.

Remediation

Upgrade to a patched version; retry prompt content now honors includecontent=False like all other message content. If you rely on this setting, consider reviewing previously exported traces for retry prompt content that should not have been recorded.

Workaround for Unpatched Versions

If you cannot upgrade, scrub or drop the message attributes (genai.input.messages, genai.output.messages, pydanticai.allmessages) in your telemetry pipeline (for example with an OpenTelemetry Collector processor), or use tool-based structured output modes, whose retry feedback honors includecontent=False.

Credits

Reported privately by the University of Sydney Security Research Team (Liyi Zhou, Ziyue Wang, Strick, Maurice, Chenchen Yu), and later independently discovered and reported publicly, with a fix, by @sean-kim05.

Summary

The Pydantic AI development web chat UI (Agent.toweb(), clai web) does not validate the Host header of incoming requests. A website a developer visits can use DNS rebinding to make requests to a chat UI running on that developer's machine appear same-origin to the browser, causing the served agent to run and to execute its tools with the privileges and credentials of the local process.

Details

Once a name the attacker controls resolves to the loopback address, the browser treats the request as same-origin, so neither an Origin check nor a CSRF token constrains it — a same-origin page can read the served UI and any token in it.

Binding the web UI to localhost — the default — does not prevent this.

Impact

Applications and developers serving an agent through Agent.toweb() or clai web. The consequences depend on the tools the served agent exposes, and can include data disclosure as well as unwanted tool side effects.

Current browser protections reduce but do not remove this exposure: Chromium's Local Network Access gates loopback subresource requests, but does not cover top-level navigations, and Safari does not implement it.

Mitigation

Upgrade to pydantic-ai/pydantic-ai-slim >= 2.30.0, or >= 1.107.5 on the v1 maintenance line.

The fix validates the Host header and rejects anything other than localhost, a loopback/LAN IP address, or an explicitly allowed host, responding 421 Misdirected Request otherwise. If you serve the web chat UI under a real hostname — behind a reverse proxy, tunnel, or similar — name it explicitly:

python app = agent.toweb(allowedhosts=['ui.example.com'])

Summary

Pydantic AI's OpenTelemetry instrumentation supports InstrumentationSettings(includecontent=False) to exclude message content — user prompts, model completions, tool call arguments and responses, and any other message content — from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend.

The message attributes honoured the setting. Several other parts of the same spans did not, and exported content regardless of it:

- Exceptions. Recorded as OpenTelemetry exception events, with their message and stack trace, on tool, agent run, model request, embedding and image generation spans, and on realtime session spans. The message of the exception carrying a tool's ModelRetry or ToolFailed feedback is the text sent back to the model, which can quote tool arguments and results. When a tool ran out of retries, the error that ended the run was chained from the last retry, so its stack trace repeated that text on the run span. Exceptions raised by tool code were recorded with their full message, as were failures of a model request, embedding or image generation, whose messages carry the provider's error response body. - The error status description. The OpenTelemetry SDK describes a span's ERROR status with the exception's type and message, so the message reached the backend a second time even where the event itself was redacted. - Instructions and the prompted-output template. The modelrequestparameters attribute serialized the request's instruction parts in full, exporting the agent's instructions — both static and those built from dependencies at request time — along with the template used to prompt for structured output.

Details

Content reaches these places because of what they carry rather than through any single missing check, which is why the setting was applied correctly to the message attributes (genai.input.messages, genai.tool.call.arguments, genai.tool.call.result, and so on) while these paths were not: the exception recording and the status description came from the OpenTelemetry SDK's defaults, and the instructions and output template were serialized as part of the request's parameters rather than treated as content.

Impact

This does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent's own data — a third-party observability vendor or a shared backend — which is the scenario includecontent=False exists for.

Who Is Affected

You are affected if you enabled instrumentation with includecontent=False. Instructions are exported on every successful run, so no failure is needed to be affected; the exception paths additionally require a tool to raise, or a model, embedding or image generation request to fail. Realtime sessions are affected the same way, through the errors their provider connections report. GHSA-3gh4-cghq-f8v4 stated that retries coming from tool calls were redacted correctly; that was true of the retry prompt in the message attributes but not of the exception event on the tool span. You are not affected if you don't set includecontent=False.

Remediation

Upgrade to a patched version. With includecontent=False, exception events now record only the exception type, error statuses carry no description, and modelrequestparameters is exported without its instruction content or output template. If you rely on this setting, consider reviewing previously exported traces for exception events, for error status descriptions, and for modelrequestparameters.

Workaround for Unpatched Versions

If you cannot upgrade, scrub the exception.message and exception.stacktrace event attributes, the error status description, and the instruction parts and promptedoutputtemplate within modelrequestparameters, on spans emitted by Pydantic AI in your telemetry pipeline (for example with an OpenTelemetry Collector processor). Setting includemodelrequestparameters=False alongside includecontent=False removes both, at the cost of the rest of that attribute.

Credits

Reported privately by @BrianWillows, whose report covered the exception events on tool and agent run spans. The remaining paths were found while fixing it, by a test that drives content through every channel at once and checks the whole exported trace.

Summary

The local web-fetch tool (webfetchtool, also used as the WebFetch capability's local fallback) processed responses with several steps whose running time grows quadratically with the size of certain server-controlled inputs, and ran them on the event loop: decoding the body with whichever charset the server declared, extracting the page title with a backtracking regular expression, and converting the HTML to markdown. An application that exposes this tool to untrusted prompts can be steered to fetch an attacker-controlled page of a megabyte or two that blocks the event loop for minutes, stalling every other coroutine in the process — other agent runs, other requests being served — for the duration.

This is an availability issue only. SSRF protections and the download size limit introduced in GHSA-v2xh-2vp8-57h8 are unaffected; that limit bounds how much is downloaded, not how long the response takes to process.

Details

Title extraction used a backtracking pattern over the raw response body, so a body made of repeated unterminated tag openings cost time proportional to the square of its size. The HTML-to-markdown conversion had the same shape in three of its steps: normalizing whitespace, stripping preformatted blocks, and numbering ordered lists all took time proportional to the square of a run of spaces or a list's length. All of it ran on the event loop, and the regex steps hold the interpreter lock even when moved off it, so the whole process paid for the size of a server-controlled response.

The response body was also decoded on the event loop with the codec named by the charset parameter of the response's Content-Type, looked up in Python's codec registry. That registry includes punycode, whose decoder takes time proportional to the square of its input: a response of about one megabyte labelled charset=punycode blocked the event loop for roughly half a minute, with no HTML required. The registry also includes codecs that aren't text encodings at all, such as rot13 and base64codec; a response labelled with one of those raised an unexpected exception out of the tool, aborting the agent run that fetched it.

Separately, the HTML-to-markdown conversion recursed once per nested element, so a page nested a few hundred elements deep raised a RecursionError out of the tool, aborting the agent run that fetched it. A JSON response nested deeper than the interpreter allows did the same. These only affect that one run.

Who Is Affected

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. alloweddomains narrows the exposure to pages on those domains but does not remove it. Applications that only fetch developer-controlled URLs are not exposed to the model-chosen attack path.

Remediation

Upgrade to a patched version. The title is now found with a single linear scan, the conversion steps above run in linear time, and decoding, title extraction and conversion all run in a worker thread. A charset naming a codec that isn't a text encoding, and a page too deeply nested to convert, are reported back to the model as a failed fetch instead of aborting the run; a JSON body too deeply nested to parse is returned as plain text.

Credits

Reported privately by @BrianWillows, whose report covered the quadratic title extraction. The response decoding, the codecs that are not text encodings, and the quadratic steps in the HTML-to-markdown conversion were found while fixing it.

Summary

When an application using Pydantic AI opts a URL into local network access — either a FileUrl with forcedownload='allow-local', or webfetchtool(allowlocalurls=True) — the cloud-metadata blocklist could be bypassed by appending an IPv6 zone identifier to a metadata address (for example fd00:ec2::254%251). The host ignores the zone identifier on a destination that is not link-local and delivers the request to the metadata endpoint anyway, exposing cloud IAM short-term credentials.

This is an incomplete fix of GHSA-cqp8-fcvh-x7r3 / CVE-2026-46678 and GHSA-cg7w-rg45-pc59 / CVE-2026-48782, themselves follow-ups to CVE-2026-25580. The parent advisory's remediation guaranteed that cloud metadata endpoints are always blocked, even with local access allowed. That guarantee did not hold for zone-scoped spellings of the IPv6 metadata endpoints.

Details

The cloud-metadata guard compared IPv6 addresses against its blocklist by set membership. Python includes the zone identifier in IPv6Address equality and hashing, so a zone-scoped spelling of a blocked address did not match, while the network stack ignores the zone identifier for a destination that is not link-local. The private-range checks, and the IPv4 and transition-form metadata checks, were already unaffected, because they compare by network containment and by packed bytes respectively.

Only the IPv6 cloud metadata endpoints were reachable this way, so the issue requires an IPv6-enabled environment — for example AWS EC2 or EKS with IPv6, GCP IPv6-only instances, or Scaleway.

Who Is Affected

You are affected only if your application opts a URL that is, or could be, influenced by untrusted input into local network access, through either:

- a FileUrl (ImageUrl, AudioUrl, VideoUrl, DocumentUrl) with forcedownload='allow-local'; or - webfetchtool(allowlocalurls=True), where the model chooses the URL.

Both are off by default.

You are not affected through the FileUrl path if you use any of the bundled integrations to ingest user input, because they do not propagate forcedownload from external data:

- Agent.toweb / clai web - VercelAIAdapter - AGUIAdapter / Agent.toagui

webfetchtool is configured by your own application, so a client cannot turn on allowlocalurls.

Applications that only download from developer-controlled URLs are not affected.

Remediation

Upgrade to a patched version. The cloud-metadata and private-IP checks now drop an IPv6 zone identifier before evaluating the address, so every blocklist comparison is made on the address itself. A zone identifier is still carried on the connection, so legitimate link-local fetches under local network access continue to work.

Workaround for Unpatched Versions

Avoid opting into local network access — forcedownload='allow-local' or webfetchtool(allowlocalurls=True) — on any URL that could be influenced by untrusted input. If you must, reject URL hosts containing % before constructing the FileUrl or configuring the tool.

Credits

Reported by @euriconicacio.

Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. From 1.77.0 until 1.107.6 and 2.44.0, the local webfetchtool and the WebFetch local fallback compare blockeddomains entries with a URL hostname before both values are normalized to the form used by getaddrinfo. An attacker-influenced model can use an equivalent IDNA spelling, non-ASCII label separator, case variation, or trailing root label that resolves to a blocked host but does not match the configured string, causing the application to fetch that host with its own privileges. alloweddomains fails closed for unmatched spellings, and private-IP and cloud-metadata protections remain effective. This issue is fixed in versions 1.107.6 and 2.44.0.

Summary

Applications using Pydantic AI's local web-fetch tool can experience excessive CPU and memory use when it converts attacker-controlled HTML. An agent must fetch the affected page; provider-native web fetching is not affected.

Details

Nested block elements cause HTML-to-Markdown conversion to reprocess accumulated text at each level and can greatly expand the intermediate output. The response-body limit bounds downloaded bytes, while the returned-content limit is applied only after conversion. On current releases, conversion runs in a worker thread but can still consume substantial resources and delay other work in the process. Older releases performed conversion on the event loop.

Mitigation

Upgrade to a patched release of pydantic-ai or pydantic-ai-slim. If you cannot upgrade yet, avoid using local web fetching for attacker-controlled HTML.

This issue was posted by Codex Desktop using gpt-6.1-sol on behalf of David.

Summary

Applications that wrap a model with ConcurrencyLimitedModel or limitmodelconcurrency can permanently lose shared concurrency capacity when a streamed request releases its slot from a different task than the one that acquired it. This can happen when a stream ends early, and also when a stream is fully consumed using the default streamtext() debouncing.

In an application that exposes an affected streaming endpoint to network clients and shares a long-lived model limiter across requests, a client can repeatedly start a stream and disconnect. The completed requests retain their slots, eventually preventing subsequent requests that share the limiter from proceeding.

Agent-level maxconcurrency and non-streaming model requests are not affected by this defect.

Details

The built-in limiter uses anyio.CapacityLimiter, which associates each acquired slot with its borrowing task. Pydantic AI's streaming lifecycle can acquire the slot on the task consuming the stream and run cleanup on another internal task. The limiter rejects that release, so the slot remains occupied even after the request has ended. Cleanup can raise a RuntimeError; a later request on the borrowing task can also fail because that task still holds a slot.

Early termination includes stopping iteration, a consumer exception, and cancellation. Fully consuming streamtext() with its default debounceby=0.1 can also reach the cross-task release path. Fully consumed streams must therefore not be assumed safe.

Mitigation

Upgrade to a patched release of pydantic-ai or pydantic-ai-slim. If you cannot upgrade yet, use the agent-level maxconcurrency setting instead of a concurrency-limited model, or avoid streaming runs through a concurrency-limited model.

Summary

A client that can submit message history to a Pydantic AI UI adapter can reference arbitrary files in the application's model-provider or cloud-storage account. The server forwards the reference to the model provider, which fetches it using the server's own credentials, allowing the client to read files it should not have access to.

Details

UI adapters reconstruct file parts from client-submitted message history and forward them to the model provider. File URL parts are validated against a scheme allowlist before being forwarded, but UploadedFile references — which point to a file by provider file ID or cloud-storage URI (e.g. s3://…, gs://…) — were forwarded without validation.

Because the provider resolves an UploadedFile using the server-side identity (IAM role, service account, or provider API key) rather than the client's, a client that crafts message history containing an attacker-chosen UploadedFile can cause the server to read objects belonging to its own account or to other tenants, given a referenceable identifier.

Impact

Applications that pass untrusted client-submitted message history to an agent through a UI adapter (such as the Vercel AI adapter). Exploitation requires the attacker to reference a valid file identifier; depending on how the application names objects, such identifiers are not always unguessable.

Patches

Upgrade to 1.106.0 (1.x) or 2.0.0b6 (the 2.x beta line), which validate UploadedFile references on client-submitted messages the same way file URLs are validated.

Workarounds

If users cannot upgrade, do not pass untrusted client-submitted message history to the agent, or strip UploadedFile parts from incoming messages before running the agent.

Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. In versions 1.88.0 up to but not including 1.107.1 and 2.0.0b1 up to but not including 2.5.0, the UI adapters (AG-UI via Agent.toagui()/AGUIAdapter, and Vercel AI via VercelAIAdapter) use sanitizemessages to strip unresolved ("dangling") client-submitted tool calls from untrusted message history before it reaches the agent, a defense-in-depth default that prevents the agent from executing tool calls the model never emitted. However, the strip anchored to a message index computed before sanitization ran, so when a trailing client message sanitized to empty and was dropped (for example a client system message under the default managesystemprompt='server'), a preceding assistant response carrying an unresolved tool call became the new tail and was dispatched without inspection. As a result, a remote client could cause a registered, non-approval server tool to run with client-supplied arguments rather than arguments the model produced. The impact is bounded by what the affected tools do and is most significant for applications that gate tool execution in a model-request hook (beforemodelrequest / aftermodelrequest), since a forged call skips the model turn and bypasses that guardrail; approval-gated tools (requiresapproval=True) are not auto-executed by this path. This issue has been fixed in versions 1.107.1 and 2.5.0.

pydantic-settings provides settings management using Pydantic. From 2.12.0 until 2.14.2, NestedSecretsSettingsSource reads secret values from files in a configured secretsdir. When secretsnestedsubdir=True, a directory entry inside secretsdir that is a symbolic link pointing outside secretsdir is followed, so files outside the configured directory are read into settings values. The same code path bypasses the documented secretsdirmaxsize protection. An attacker or lower-privileged component able to influence entries in the configured secrets directory (for example, a writable or shared secrets mount) can turn this into an unintended local file read into settings and can defeat the advertised loading-size cap. This vulnerability is fixed in 2.14.2.

Summary

When an application using Pydantic AI opts a URL into forcedownload='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 forcedownload='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 forcedownload from external data:

- Agent.toweb / clai web - VercelAIAdapter - AGUIAdapter / Agent.toagui

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 forcedownload='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.

Summary

When an application using Pydantic AI opts a URL into forcedownload='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 / 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 forcedownload='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 forcedownload from external data:

- Agent.toweb / clai web - VercelAIAdapter - AGUIAdapter / Agent.toagui

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 forcedownload='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.

Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. From 0.0.26 to before 1.56.0, aServer-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. This vulnerability is fixed in 1.56.0.

Summary

A Path Traversal vulnerability in the Pydantic AI web UI 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.toweb 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.toweb 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 htmlsource parameter is available on Agent.toweb and createwebapp 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.

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.toweb or clai web to serve a chat interface - VercelAIAdapter for Vercel AI SDK integration - AGUIAdapter or Agent.toagui 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 downloaditem() 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.toweb 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.toagui - 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 forcedownload='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 pydanticai 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", forcedownload='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 to filter out URLs targeting local/private addresses:

python import ipaddress import socket from urllib.parse import urlparse

from pydanticai import Agent, ModelMessage, ModelRequest from pydanticai.messages import AudioUrl, DocumentUrl, ImageUrl, VideoUrl

def isprivateurl(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 ipstr = socket.gethostbyname(hostname) ip = ipaddress.ipaddress(ipstr)

# Block private, loopback, and link-local addresses return ip.isprivate or ip.isloopback or ip.islinklocal except (socket.gaierror, ValueError): return True # DNS resolution failed, block it

def filterprivateurls(messages: list[ModelMessage]) -> list[ModelMessage]: """Remove URL parts that target private/internal addresses.""" urltypes = (ImageUrl, AudioUrl, VideoUrl, DocumentUrl) filtered = [] for msg in messages: if isinstance(msg, ModelRequest): safeparts = [ part for part in msg.parts if not (isinstance(part, urltypes) and isprivateurl(part.url)) ] if safeparts: filtered.append(ModelRequest(parts=safeparts)) else: filtered.append(msg) return filtered

Apply the filter to your agent agent = Agent('openai:gpt-5', historyprocessors=[filterprivateurls])

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)

Last updated 12 November 2024

Impact

Passing either 'infinity', 'inf' or float('inf') (or their negatives) to datetime or date fields causes validation to run forever with 100% CPU usage (on one CPU). Patches

Pydantic is be patched with fixes available in the following versions:

v1.8.2 v1.7.4 v1.6.2

All these versions are available on pypi, and will be available on conda-forge soon.

See the changelog for details. Workarounds

If you absolutely can't upgrade, you can work around this risk using a validator to catch these values, brief demo:

from datetime import date from pydantic import BaseModel, validator

class DemoModel(BaseModel): dateofbirth: date

@validator('dateofbirth', pre=True) def skipinfinitevalues(cls, v): try: seconds = float(v) except (ValueError, TypeError): return v else: if seconds == float('inf'): return date.max elif seconds == float('-inf'): return date.min else: return seconds

Note: this is not an ideal solution (in particular you'll need a slightly different function for datetimes), instead of a hack like this you should upgrade pydantic.

If you are not using v1.8.x, v1.7.x or v1.6.x and are unable to upgrade to a fixed version of pydantic, please create an issue requesting a back-port, and we will endeavour to release a patch for earlier versions of pydantic. References

This was fixed in commit 7e83fdd.