PraisonAI is a multi-agent teams system. Prior to version 4.6.40, PraisonAI's first-party A2A server example exposes an unauthenticated A2A JSON-RPC endpoint and registers a `calculate(expression)` tool implemented with Python `eval()`. The example also binds to `0.0.0.0`. A remote unauthenticated attacker can send `message/send` to `/a2a`; the request reaches `agent.chat()`, and a real LLM can invoke the registered `calculate` tool. In testing with `gemini/gemini-2.5-flash-lite`, this resulted in arbitrary Python execution in the server process, confirmed by creation of a marker file from an unauthenticated HTTP request. The issue affects deployments following the official A2A example or similar unauthenticated public A2A deployments with unsafe tools. The default unauthenticated A2A surface also exposes task history and task cancellation APIs, increasing confidentiality and integrity impact. Version 4.6.40 patches the issue.

Affected: PyPI: PraisonAI

## Summary

The first-party PraisonAI A2A server example combines three behaviors into a remotely exploitable Critical chain:

1. The example exposes an A2A server without configuring `auth_token`. 2. The same example binds the server to `0.0.0.0`. 3. The example registers a `calculate(expression)` tool implemented with Python `eval(expression)`.

An unauthenticated network client can send a JSON-RPC `message/send` request to `/a2a`. The A2A handler passes the attacker-controlled message to `agent.chat()`. With a real Gemini LLM (`gemini/gemini-2.5-flash-lite`), the model invoked the registered `calculate` tool, causing the example's `eval()` call to execute Python in the server process. The canary wrote a marker file from an unauthenticated `/a2a` request.

This is not a claim that every A2A deployment is automatically RCE. The Critical chain is confirmed for the first-party A2A example, and for deployments that follow the same pattern: public unauthenticated A2A plus an unsafe tool such as this `eval()`-based `calculate` tool. The default unauthenticated A2A surface is the remote entry point; the official example's `eval()` tool provides the code execution sink.

Earlier note:

The unsafe official example existed earlier, but the complete unauthenticated `/a2a` `message/send` to `agent.chat()` exploit chain is only claimed here for versions where that endpoint is present and confirmed.

## Trust Boundary

The boundary that should be preserved is:

```text Unauthenticated…

Affected: PyPI: praisonai

## Summary

The first-party PraisonAI A2A server example combines three behaviors into a remotely exploitable Critical chain:

1. The example exposes an A2A server without configuring `auth_token`. 2. The same example binds the server to `0.0.0.0`. 3. The example registers a `calculate(expression)` tool implemented with Python `eval(expression)`.

An unauthenticated network client can send a JSON-RPC `message/send` request to `/a2a`. The A2A handler passes the attacker-controlled message to `agent.chat()`. With a real Gemini LLM (`gemini/gemini-2.5-flash-lite`), the model invoked the registered `calculate` tool, causing the example's `eval()` call to execute Python in the server process. The canary wrote a marker file from an unauthenticated `/a2a` request.

This is not a claim that every A2A deployment is automatically RCE. The Critical chain is confirmed for the first-party A2A example, and for deployments that follow the same pattern: public unauthenticated A2A plus an unsafe tool such as this `eval()`-based `calculate` tool. The default unauthenticated A2A surface is the remote entry point; the official example's `eval()` tool provides the code execution sink.

Earlier note:

The unsafe official example existed earlier, but the complete unauthenticated `/a2a` `message/send` to `agent.chat()` exploit chain is only claimed here for versions where that endpoint is present and confirmed.

## Trust Boundary

The boundary that should be preserved is:

```text Unauthenticated…