pydantic-ai v2.66.0 — v2.66.0 (2026-11-04)

Pydantic AI, the Python framework for building LLM agents from the team behind Pydantic, opens the notes for version 2.66.0 with ten security advisories: two rated high, seven medium and one low. Eight are fixed in pydantic-ai 2.66.0, and seven of those also ship in 1.107.10 for the version 1 line. One of the two high-severity issues is in the separate pydantic-ai-harness package and is fixed only in its version 0.66.0, which also carries the low-severity fix, so upgrading pydantic-ai alone does not cover it. The tenth was fixed in an earlier release. Whether an application is exposed depends less on the severity labels than on how it is deployed. Eight of the ten advisories need someone outside the application to supply some of its input, such as a URL to fetch, a tool schema, a chat history or data a tool returns. The other two concern credentials reaching people who can read traces or use the chat frontend.

Five of the advisories are the same kind of problem. In an asynchronous Python application, the event loop runs many tasks on one thread, so one slow step holds up all other work in the process. The notes describe crafted input that makes such a step far slower than it should be: a deeply nested JSON document fetched by `web_fetch_tool` that expands to hundreds of times its size when re-indented, a few hundred characters that keep the harness's default private-key redaction pattern busy for minutes or longer, tool schemas whose definitions reference one another and expand exponentially, and submitted messages whose load time grows with the square of the number of parts. Three of these name the AG-UI or Vercel AI adapters, which connect an agent to a chat frontend and accept conversations or frontend tool schemas from its clients. The one in decision models such as `OpenAIDecisionsModel` affects versions from 2.46.0 onward and is fixed only in 2.66.0.

Three more can expose data. On Tencent Cloud, an application that allows local URLs could be made to fetch the instance's temporary role credentials from the metadata address 169.254.0.23, which the download blocklist did not include. When stored message history was loaded again, a tool result shaped like one of Pydantic AI's file types was rebuilt as a file, so a third party who controls what a tool returns could make the application download a URL on its local network, or make the model provider read an `s3://` object or uploaded file with the application's credentials. That one matters for applications that store and reload history, including through Temporal, DBOS or Prefect durable execution, and the advisory lists which models and providers fetch such files. The low-severity fix makes domain allowlists reject a refused hostname before looking it up in DNS, because the lookup alone could carry data encoded in the hostname to that domain's nameserver.

For the last two, upgrading does not undo the exposure. With OpenTelemetry instrumentation enabled for embedding models, secrets passed through the `extra_headers` or `extra_body` settings were recorded in trace spans, and the notes advise restricting access to historical traces and rotating any credentials they exposed. The final advisory was already fixed in 2.60.0 and is only disclosed now. From 2.57.0 until that fix, an MCP server configured by URL without an explicit id took its identifier from the URL's hostname and last path segment, and the AG-UI and Vercel AI adapters sent that identifier to the chat frontend, so a credential in that segment could reach its users. The 2.60.0 release changed the default identifier to the hostname alone. Anyone who carried MCP server credentials in the URL path should rotate them. This explanation is based on the release notes; the individual advisory pages were not read.