PraisonAI EUVD-2026-42900

Exploitation requires that (1) the attacker controls a PraisonAI workflow file AND its sibling tools.py in the same directory, (2) the workflow step uses a string-typed output_pydantic reference (the specific feature that triggers _resolve_pydantic_class's directory search), and (3) a victim executes that workflow via WorkflowManager or after load_yaml. Limiting factors: the vector is local (AV:L) not network, and success depends on victim interaction (UI:P) - the target must actually load and run the attacker-supplied workflow - so this is not remotely triggerable against a default service. The normally-protective PRAISONAI_ALLOW_*_TOOLS environment variables do NOT limit this path because the vulnerable loader ignores them, removing a control operators may assume is in place.

The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, VC:H/VI:H/VA:H, base 8.5) frames this as a high-impact but locally-scoped, interaction-dependent issue: full confidentiality, integrity and availability loss on the vulnerable system, but only after a victim executes a workflow the attacker influenced (UI:P). This is effectively a malicious-file / untrusted-input code-execution class, not a remote unauthenticated network exploit - the practical prerequisite is that the attacker controls both the workflow file and its sibling tools.py that the runner then loads. No EPSS score, KEV listing, or public POC was provided, so real-world exploitation pressure appears low-to-targeted rather than mass-scan driven; the danger concentrates in environments that ingest, share, or auto-execute third-party PraisonAI workflows. Note a tension worth verifying: PR:N implies no privileges, yet exploitation requires the attacker to place files the victim loads, so the true barrier is delivery and victim execution rather than authentication.

An attacker publishes or shares a seemingly benign PraisonAI workflow file (e.g., in a repo, template gallery, or shared directory) that uses a string output_pydantic reference and ships a malicious sibling tools.py containing top-level code such as a reverse shell. When a victim loads and runs that workflow via WorkflowManager or load_yaml, importlib exec_module executes the tools.py and the attacker's Python runs with the runner's privileges. No public POC has been identified, and the local vector plus required user execution (UI:P) mean the attacker depends on social delivery of the workflow rather than remote triggering.