Pydantic AI Web Chat UI: Any Website Could Run Your Local Agent

On 8 October 2026, Pydantic published nine security advisories for Pydantic AI. The two that most developers should act on concern the built-in web chat UI, started with Agent.to_web() or clai web. A website open in the developer's browser could make that local UI run the agent and execute its tools, with the privileges and credentials of the developer's process.

Binding the UI to localhost, which is the default, does not prevent either bug. The fixes have been on PyPI since August, so this is mostly a question of whether old versions are still in virtual environments that get used.

What's affected

Both web UI bugs affect pydantic-ai and pydantic-ai-slim from 1.34.0 onward:

• CVE-2026-107295 (high, CVSS 7.6): the chat endpoint didn't check the request content type, so a page on any website the developer visited could submit a chat request to it. Fixed in 2.28.0 and, on the v1 maintenance line, 1.107.4 (both uploaded 12 August 2026). The advisory adds that tools marked requires_approval=True were not protected either, because the endpoint trusted approval decisions relayed by the client.
• CVE-2026-107292 (medium, 6.4): the server didn't validate the Host header, so DNS rebinding made a page on an attacker's domain look same-origin to the browser. At that point neither an Origin check nor a CSRF token helps. Fixed in 2.30.0 and 1.107.5 (both uploaded 14 August 2026).

The same day's batch also covers the library itself:

• CVE-2026-107289: the cloud metadata blocklist could be bypassed with an IPv6 zone identifier, such as fd00:ec2::254%251, when an app opted into local URLs with force_download='allow-local' or web_fetch_tool(allow_local_urls=True). Fixed in 2.44.0 and 1.107.6.
• CVE-2026-107286 (high): concurrency-limited models could lose slots permanently when a stream ended early, letting a client exhaust a shared limiter by connecting and disconnecting. Fixed in 2.53.0, affects 2.10.0 onward.
• Three resource exhaustion bugs in web_fetch and FileUrl downloads, and two OpenTelemetry bugs that recorded content when include_content=False.

Upgrading to 2.53.0 or later on v2, or 1.107.7 or later on v1, covers all nine where they apply.

How to check if you're exposed

Check versions in every environment where developers run agents, not just production images:

pip show pydantic-ai pydantic-ai-slim 2>/dev/null | grep -E '^(Name|Version)'
uv pip list 2>/dev/null | grep -i pydantic-ai

Then find whether anyone serves the web UI. It is a development tool, so look in scripts, notebooks and Makefiles as well as application code:

grep -rnE '\.to_web\(|clai web' --include=*.py --include=*.sh --include=Makefile --include=*.ipynb .

Reachability depends on two things. First, a web UI process has to be running while the developer browses. Second, the agent behind it needs tools worth abusing. An agent with only read-only, offline tools exposes little. An agent with shell access, file writes, a database connection or a cloud SDK exposes all of that to any page the developer opens.

If you serve the UI on a real hostname behind a reverse proxy or tunnel, you are also in scope, and you will need a config change after upgrading (see below).

What to do now

1. Upgrade pydantic-ai or pydantic-ai-slim to 2.53.0 or later, or 1.107.7 or later on the v1 line. The minimum for the two web UI bugs alone is 2.30.0 or 1.107.5.

2. If you serve the UI under a hostname, name it explicitly, because the fix now rejects unknown hosts with 421 Misdirected Request:

   app = agent.to_web(allowed_hosts=['ui.example.com'])
   

3. Update any script that posts to the chat endpoint directly. The patched endpoint requires Content-Type: application/json and rejects other requests before parsing.

4. Stop the web UI when you aren't using it. That was the advisory's workaround before the fix, and it still costs nothing.

5. Don't serve agents with side-effecting tools through a development UI. Keep a separate, tool-free agent for UI experiments.

6. If you opted into local URL access, check that apps running on cloud hosts were upgraded past 2.44.0 or 1.107.6, since CVE-2026-107289 exposes instance metadata credentials.

Why it matters

"It only listens on localhost" has never been a security boundary against the browser. The browser runs on the same machine and will happily send requests to 127.0.0.1 on behalf of any page. Chromium's Local Network Access checks help with subresource requests, but the advisory notes they don't cover top-level navigations and Safari doesn't implement them.

Local agent UIs make the old problem worse because the thing listening is no longer a static dev server. It is a process holding model keys and tools that act. Treat every local agent endpoint the way you would a local database admin panel: authenticated, host-checked, and off when idle.

Try it yourself

Start an agent with agent.to_web() on an old version in a throwaway virtualenv, then upgrade and confirm a request with a wrong Host header now gets a 421. Then see how a developer-side gate flags vulnerable package versions before they land in a local environment:

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GHSA-h4xc-3qfq-jf93: Web chat UI can be driven by a website the developer visits (CVE-2026-107295)
• GHSA-q2xc-rrxj-58x9: Web chat UI does not validate the Host header (CVE-2026-107292)
• GHSA-vmxc-h2x2-jmf3: SSRF metadata blocklist bypass via IPv6 zone identifiers (CVE-2026-107289)
• GHSA-6fqq-452j-qhrp: Concurrency-limited models keep slots after early stream end (CVE-2026-107286)
• Pydantic AI web chat UI documentation
• pydantic-ai on PyPI