A Browser Tab Could Quietly Drive Pydantic AI's Local Chat UI, Approval Gates Included

CVE-2026-107295 let any website a developer visited trigger agent runs and tool calls through the Pydantic AI development web chat UI, even when it was bound to localhost. Fixes shipped in pydantic-ai 2.28.0 and 1.107.4.

A web browser tab sending a hidden arrow into a laptop's local agent chat window
A web browser tab sending a hidden arrow into a laptop's local agent chat window

Pydantic AI has patched a flaw in its development web chat UI that let an ordinary website trigger agent runs on a developer’s own machine. Tracked as CVE-2026-107295 and published in the GitHub Advisory Database as GHSA-h4xc-3qfq-jf93 on October 8, 2026, the issue affects the chat interface exposed by Agent.to_web() and the clai web command. GitHub rates it High, with a CVSS 3.1 score of 7.6.

Fixed versions are available on both maintained release lines: pydantic-ai and pydantic-ai-slim 2.28.0 for the 2.x series, and 1.107.4 for the 1.x series. The vulnerable ranges are 2.0.0b1 up to 2.28.0, and 1.34.0 up to 1.107.4.

Why localhost was not a boundary

Pydantic AI is the agent framework from the team behind the Pydantic validation library. Its web chat UI is a convenience feature: a developer wraps an agent, starts a small local server, and talks to the agent in a browser while building it. By default that server binds to the loopback address, which many developers treat as a private space.

According to the advisory, the chat endpoint did not check the content type of incoming requests. That gap matters because of how browsers handle cross-origin traffic. A web page can send certain “simple” requests, such as a form-style POST, to any address, including 127.0.0.1, without a preflight check. The page cannot necessarily read the response, but the request still lands. If the receiving server does not insist on a header that only same-origin scripts can set, it has no way to tell a legitimate call from a forged one.

The maintainers state this plainly in the advisory: binding the web UI to localhost, the default, does not prevent the attack, because a page open in the developer’s browser can reach the loopback address.

What an attacker could make the agent do

The impact depends entirely on the agent being served. Once a forged request reached the endpoint, the agent would run and execute its tools with the privileges and credentials of the local process. For an agent wired to a file system, a shell, a database, or a cloud API, that could mean data disclosure or unwanted side effects, triggered by nothing more than the developer visiting a malicious or compromised page while the UI was running.

One detail stands out. Pydantic AI lets developers mark sensitive tools with requires_approval=True, so a human has to confirm the call before it executes. The advisory says those tools were not protected either, because the endpoint trusted approval decisions relayed by the client. In other words, the forged request could carry its own “approved” answer. A safeguard designed to keep a human in the loop was enforced on the wrong side of the connection.

GitHub’s scoring reflects that profile: network-reachable, low complexity, no privileges required, but dependent on user interaction, since the developer has to load the attacker’s page. Integrity impact is rated high; confidentiality and availability impact are rated low.

How the fix works

The patch is narrow. The chat endpoint now requires Content-Type: application/json and rejects any other request before the body is parsed and before the agent runs. Browsers will not attach that header to a cross-origin request without a CORS preflight, which the local server does not grant, so the forged-request path closes.

The bundled chat UI already sends the header, so ordinary use is unaffected. The maintainers note that scripts and other non-browser clients that call the endpoint directly may need to be updated to send it.

For teams that cannot upgrade right away, the advisory lists three interim steps: do not run the web UI while browsing untrusted sites, stop it when it is not in use, and do not serve an agent with side-effecting tools through it.

The issue was credited to Thai Son Dinh of VinSOC Labs.

A recurring pattern in agent tooling

The bug fits a class that keeps resurfacing as agent frameworks add local developer conveniences: dashboards, inspectors, and chat consoles that listen on a loopback port and assume only the developer can reach them. Traditional web applications learned long ago that cookies and localhost are not authentication, and that state-changing endpoints need either strict content-type checks, origin validation, or anti-forgery tokens.

Agent tooling raises the stakes, because the endpoint does not just change a record; it hands control to a model that can call tools. A forged request that would once have toggled a setting can now ask an agent to read files or call an API with real credentials.

For Pydantic AI users, the practical step is simple. Check which version is installed with pip show pydantic-ai pydantic-ai-slim, move to 2.28.0 or 1.107.4 or later, and treat any locally served agent with powerful tools as reachable from the browser until proven otherwise.

Topics
  • #Pydantic AI
  • #CVE-2026-107295
  • #Agent Security
  • #CSRF
  • #Python
Raj M

Author

Raj M

Contributor

AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.