PraisonAI's unauthenticated A2A official example can reach real LLM-driven `eval()` tool execution
Date: 2026-05
Affected: pip/PraisonAI
Attack vector: info-disclosure
Category: vulnerability-disclosure
Severity: Critical
CVE: CVE-2026-47391
CWE: CWE-306
CWE-95
CVSS: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

## 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 n


Mitigations:

Architectural layers (MAESTRO):