PraisonAI EUVD-2026-108896

Requires an operator to execute an untrusted, attacker-authored steps-based recipe (hence UI:R) on an affected version (>=4.5.87, <4.6.61). The crafted recipe must: omit execute_command from TEMPLATE.yaml requires.tools (so it passes _check_tool_policy, which only inspects TEMPLATE.yaml), declare execute_command under workflow.yaml agents.*.tools, and set a top-level approve:[execute_command] that YAMLWorkflowParser preserves and Workflow.start()/set_yaml_approved_tools installs as approved. The caller must NOT have passed allow_dangerous_tools=True (if they had, the behavior is the intended opt-in). Limiting factors: exploitation is local by default and depends on the operator choosing to run the untrusted recipe, and actual command execution still depends on the model/agent tool-call path reaching execute_command - though the policy boundary is bypassed before that point. The bundled HTTP recipe runner defaults to localhost/no-auth and requires auth for non-localhost binding, so remote exploitation is only possible in non-default deployments that expose the API to users who can select recipe names/URIs.

Signals point to a real but conditional priority rather than a mass-exploitation emergency. The CVSS 3.1 base score is 7.8 (High) with vector AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, so the headline severity is driven by full compromise (C:H/I:H/A:H via arbitrary shell execution) but gated by local vector and required user interaction - specifically an operator who runs an untrusted recipe. The vuln.today decision label is 'this_week', consistent with a serious issue that is not act_now/emergency. No EPSS score was supplied and the CVE is not listed in CISA KEV, so there is no evidence of active or widespread exploitation; the only exploitation artifact is the local PoV described in the GHSA advisory (a harmless printf canary with PRAISONAI_AUTO_APPROVE unset), which demonstrates the policy bypass deterministically but is a researcher reproduction rather than confirmed in-the-wild use. One tension to verify: the CVSS vector encodes AV:L, yet the advisory explicitly notes that an HTTP recipe-runner deployment exposed to authenticated users who choose recipe names/URIs could turn this into an authenticated remote recipe-execution issue - the vendor deliberately chose local/UI-required severity as the default claim, so network exploitability depends on non-default deployment and should be assessed per environment. Net: treat as a high-value supply-chain/untrusted-recipe risk for anyone running recipes from untrusted sources, but not an unauthenticated internet-facing RCE by default.

An operator (or a user allowed to pick recipe names/URIs on a recipe-runner deployment) executes an attacker-authored steps-based recipe. The recipe omits execute_command from TEMPLATE.yaml requires.tools so it passes the dangerous-tool policy, but declares execute_command under workflow.yaml agents.*.tools with top-level approve:[execute_command]; Workflow.start() self-approves the critical shell tool and runs commands with the PraisonAI process privileges, even though the caller never set allow_dangerous_tools=True. A vendor PoV in the GHSA advisory reproduces the bypass locally (harmless printf canary), though it is not verified as weaponized exploit code.