Pydantic AI CVE-2026-107292

Requires a developer to be running the Pydantic AI development web chat UI via Agent.to_web() or clai web on an affected version (pydantic-ai/pydantic-ai-slim 1.34.0-<1.107.5 or 2.0.0b1-<2.30.0), typically bound to localhost. The attacker must control a DNS name and rebind it to the loopback address, and the targeted developer must visit the attacker's page in the same browser (UI:R). The blast radius is defined precisely by which tools the served agent exposes - data disclosure plus any side effects those tools can perform with the local process's credentials. Limiting factors: the feature is developer/debug-oriented rather than a production service; required user interaction and attacker-controlled DNS with rebind timing raise complexity (AC:H); Chromium's Local Network Access gates loopback subresource requests (but not top-level navigations), and Safari does not implement it, so browser protections reduce but do not eliminate exposure; localhost binding, Origin checks, and CSRF tokens do NOT mitigate it.

This is a genuine but conditional, medium-severity issue rather than a top-priority fire drill. The input CVSS of 6.4 (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:L) is internally consistent with the description: network-reachable via the browser, but gated by high attack complexity (DNS rebinding requires attacker-controlled DNS, timing/rebind of a name to loopback, and a race against the browser) and by required user interaction (the developer must visit a hostile page in the same browser). No EPSS score, KEV listing, or public POC is present in the supplied data, so exploitation is 'no public exploit identified at time of analysis' - there is no evidence of active or widespread exploitation. The key tension is that the vulnerable surface, Agent.to_web()/clai web, is an explicitly developer-facing local chat server, not a production service, which narrows the realistic target population and tempers the AV:N 'network' framing (the bind is to localhost by default; reachability comes only through the DNS-rebinding same-origin trick, not a directly exposed port). Overall real impact is bounded by, and entirely dependent on, which tools the served agent exposes - a read-only agent leaks served UI/credentials (C:L), while an agent with powerful tools yields meaningful integrity impact (I:H). Treat as a 'patch promptly on dev machines' item, not an emergency; no key signals conflict, but note the absence of EPSS/KEV/POC data means prevalence of exploitation cannot be quantified from the input.

A developer running clai web or an app using Agent.to_web() on localhost visits an attacker-controlled website in the same browser. The page uses DNS rebinding to point a name it controls at 127.0.0.1, so the browser treats it as same-origin with the local chat UI, defeating the localhost bind, Origin checks, and CSRF tokens. The hostile page then reads the served UI and submits chat requests that drive the agent's tools with the local process's privileges and credentials. No public exploit is identified at time of analysis, though the technique (DNS rebinding) is well understood and the high complexity reflects setup and timing rather than deep novelty.