Summary
A missing request Content-Type check in Pydantic AI's web development chat endpoints can allow a website visited by a developer to send a browser-compatible request to a locally hosted agent server. The agent may then execute configured tools using the local process's privileges and credentials, even when the server is bound only to localhost.
A missing request Content-Type check in Pydantic AI's web development chat endpoints can allow a website visited by a developer to send a browser-compatible request to a locally hosted agent server. The agent may then execute configured tools using the local process's privileges and credentials, even when the server is bound only to localhost.
Affected context
The issue occurs in deployments that expose Pydantic AI's Agent.to_web() or the clai web development chat endpoint through a loopback-hosted server. It becomes risky when:
- A developer runs the chat server on a local machine
- A browser can reach the loopback endpoint
- The endpoint does not validate request Content-Type or equivalent cross-origin request properties
- The served agent has tools that can access local files, services, credentials, or other privileged resources
The issue occurs in deployments that expose Pydantic AI's Agent.to_web() or the clai web development chat endpoint through a loopback-hosted server. It becomes risky when:
- A developer runs the chat server on a local machine
- A browser can reach the loopback endpoint
- The endpoint does not validate request Content-Type or equivalent cross-origin request properties
- The served agent has tools that can access local files, services, credentials, or other privileged resources
Exploit preconditions
- Attack surface: A browser-accessible local web chat endpoint
- Required access: The victim must run the affected agent server and visit or load a page controlled by an attacker
- Trigger point: The malicious page causes the browser to submit a browser-compatible request to the loopback chat endpoint
- Why exploitation is possible: Missing request Content-Type validation allows cross-site browser requests to be accepted as legitimate agent interactions
- Additional concern: Client-relayed approval decisions may leave tools marked
requires_approval=Trueexposed to unauthorized requests
- Attack surface: A browser-accessible local web chat endpoint
- Required access: The victim must run the affected agent server and visit or load a page controlled by an attacker
- Trigger point: The malicious page causes the browser to submit a browser-compatible request to the loopback chat endpoint
- Why exploitation is possible: Missing request Content-Type validation allows cross-site browser requests to be accepted as legitimate agent interactions
- Additional concern: Client-relayed approval decisions may leave tools marked
requires_approval=Trueexposed to unauthorized requests
Why this happens
The underlying flaw is insufficient cross-origin request validation at a state-changing web endpoint. The server accepts requests that a browser can generate from another origin without requiring a non-simple Content-Type or another equivalent trusted-request signal.
This maps to CWE-352: Cross-Site Request Forgery, because an attacker-controlled website can cause a user's browser to invoke an action in a local application using the browser's network reachability and the application's available authority. Binding the service to localhost is not, by itself, a sufficient origin or request-authentication boundary.
The underlying flaw is insufficient cross-origin request validation at a state-changing web endpoint. The server accepts requests that a browser can generate from another origin without requiring a non-simple Content-Type or another equivalent trusted-request signal.
This maps to CWE-352: Cross-Site Request Forgery, because an attacker-controlled website can cause a user's browser to invoke an action in a local application using the browser's network reachability and the application's available authority. Binding the service to localhost is not, by itself, a sufficient origin or request-authentication boundary.
Potential impact
- An agent may execute tools without the developer's intended interaction
- Local files, services, or environment-backed credentials could be accessed
- The local process may perform unauthorized actions with its existing privileges
- Sensitive tool output could be returned to or indirectly exposed through the chat workflow
- Approval-gated tools may be invoked when approval state is trusted from the client
- An agent may execute tools without the developer's intended interaction
- Local files, services, or environment-backed credentials could be accessed
- The local process may perform unauthorized actions with its existing privileges
- Sensitive tool output could be returned to or indirectly exposed through the chat workflow
- Approval-gated tools may be invoked when approval state is trusted from the client
General mitigation guidance
Mitigation generally focuses on treating loopback web interfaces as security-sensitive APIs rather than trusted local utilities.
Common defensive patterns include:
- Enforcing strict request Content-Type, origin, and trusted-client checks for state-changing endpoints
- Using an unpredictable per-session token or equivalent server-verified CSRF protection
- Avoiding client-controlled approval decisions; keep approval state authoritative on the server
- Requiring explicit authentication before agent or tool execution
- Limiting agent tools and running the process with least privilege
- Binding sensitive services only to the interfaces and networks that require access
- Avoiding access to ambient credentials and high-impact local resources from development agents
Mitigation generally focuses on treating loopback web interfaces as security-sensitive APIs rather than trusted local utilities.
Common defensive patterns include:
- Enforcing strict request Content-Type, origin, and trusted-client checks for state-changing endpoints
- Using an unpredictable per-session token or equivalent server-verified CSRF protection
- Avoiding client-controlled approval decisions; keep approval state authoritative on the server
- Requiring explicit authentication before agent or tool execution
- Limiting agent tools and running the process with least privilege
- Binding sensitive services only to the interfaces and networks that require access
- Avoiding access to ambient credentials and high-impact local resources from development agents
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for state-changing endpoints without origin, token, or Content-Type validation
- Tests that submit browser-compatible cross-origin requests to local development services
- Review of web routes that invoke agent tools or rely on client-supplied approval fields
- Network and application logging for unexpected requests from local browser contexts
- Policy enforcement requiring authentication and CSRF defenses on loopback HTTP services
Automated security review tools may help identify missing request validation, but endpoint behavior should also be verified with browser-based integration tests.
Organizations can look for this class of issue through:
- Static analysis and code review checks for state-changing endpoints without origin, token, or Content-Type validation
- Tests that submit browser-compatible cross-origin requests to local development services
- Review of web routes that invoke agent tools or rely on client-supplied approval fields
- Network and application logging for unexpected requests from local browser contexts
- Policy enforcement requiring authentication and CSRF defenses on loopback HTTP services
Automated security review tools may help identify missing request validation, but endpoint behavior should also be verified with browser-based integration tests.
