CVE-2026-57142: PraisonAI: recipe policy bypass self-approves shell tool

HIGH

Published October 23, 2026

CISO Take

PraisonAI versions 4.5.87 through 4.6.60 enforce their dangerous-tool policy only against tools declared in TEMPLATE.yaml, so an untrusted recipe can declare execute_command in workflow.yaml and add a top-level approve list. The workflow then self-approves the shell tool without the caller ever setting allow_dangerous_tools=True, which gives arbitrary command execution (CWE-78/94/863) with full confidentiality, integrity and availability impact. Exposure is limited because the attacker must get a user to run a malicious recipe (local vector, user interaction required). There is no KEV listing, no public exploit, no Nuclei template and no EPSS score yet, so urgency is moderate, but teams that pull community recipes into agent workflows should treat this as high priority. Upgrade to 4.6.61 or later, and until then run only recipes you have reviewed.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

High (CVSS 7.8). Exploitation is low complexity and needs no privileges, but a user must execute an attacker-supplied recipe, which lowers likelihood. The risk rises where recipes are shared, downloaded from registries or generated by third parties, and where agents run on developer workstations or CI runners with access to credentials and source code. Not in CISA KEV, with no known public exploit or scanner template, so there is no evidence of active exploitation. The bypass is simple to reproduce from the advisory description, so weaponization is likely to be quick.

How does the attack unfold?

Delivery

Attacker distributes a malicious recipe whose TEMPLATE.yaml looks benign and omits execute_command from requires.tools.

AML.T0011.002

Policy Bypass

workflow.yaml declares execute_command under agents.*.tools and adds a top-level approve list, so the policy check passes and the workflow self-approves the shell tool.

AML.T0081

Execution

The agent invokes execute_command and runs attacker-controlled shell commands on the host.

AML.T0053

Impact

Attacker steals credentials and source code, installs persistence or pivots to other systems.

AML.T0050

Delivery

Attacker distributes a malicious recipe whose TEMPLATE.yaml looks benign and omits execute_command from requires.tools.

AML.T0011.002

Policy Bypass

workflow.yaml declares execute_command under agents.*.tools and adds a top-level approve list, so the policy check passes and the workflow self-approves the shell tool.

AML.T0081

Execution

The agent invokes execute_command and runs attacker-controlled shell commands on the host.

AML.T0053

Impact

Attacker steals credentials and source code, installs persistence or pivots to other systems.

AML.T0050

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	—	No patch
1 dependents61% patched~23d to patchFull package profile →

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1

7.8 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 15% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVLocal

ACLow

PRNone

UIRequired

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Upgrade praisonai to 4.6.61 or later. 2) Until patched, run only recipes from trusted, reviewed sources and inspect workflow.yaml for agents.*.tools entries and top-level approve: lists, especially execute_command or other shell tools. 3) Run PraisonAI in a sandbox or container with minimal privileges, no long-lived credentials and restricted egress. 4) Do not run recipes automatically in CI without review. 5) Detect by auditing recipe repositories for workflow.yaml files whose tools or approve entries are not declared in TEMPLATE.yaml requires.tools, and by monitoring for unexpected child shell processes spawned by the PraisonAI process.

How is it classified?

Code ExecutionAuth BypassSupply ChainAgentFrameworkPluginAML.T0011.002- Poisoned AI Agent Tool AML.T0050- Command and Scripting Interpreter AML.T0053- AI Agent Tool Invocation AML.T0081- Modify AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Mechanisms to respond to and recover from unknown risks

OWASP LLM Top 10

LLM03-Supply ChainLLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-57142?

Is CVE-2026-57142 actively exploited?

No confirmed active exploitation of CVE-2026-57142 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-57142?

1) Upgrade praisonai to 4.6.61 or later. 2) Until patched, run only recipes from trusted, reviewed sources and inspect workflow.yaml for agents.*.tools entries and top-level approve: lists, especially execute_command or other shell tools. 3) Run PraisonAI in a sandbox or container with minimal privileges, no long-lived credentials and restricted egress. 4) Do not run recipes automatically in CI without review. 5) Detect by auditing recipe repositories for workflow.yaml files whose tools or approve entries are not declared in TEMPLATE.yaml requires.tools, and by monitoring for unexpected child shell processes spawned by the PraisonAI process.

What systems are affected by CVE-2026-57142?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, workflow/recipe execution, developer workstations and CI runners running agents.

What is the CVSS score for CVE-2026-57142?

CVE-2026-57142 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.24%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-agent orchestrationworkflow/recipe executiondeveloper workstations and CI runners running agents

MITRE ATLAS Techniques

AML.T0011.002Poisoned AI Agent Tool

AML.T0050Command and Scripting Interpreter

AML.T0053AI Agent Tool Invocation

AML.T0081Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03, LLM06

What are the technical details?

Original Advisory

PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.61, PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools. For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context. As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool. This issue has been patched in version 4.6.61.

Exploitation Scenario

An attacker publishes a helpful-looking PraisonAI recipe to a community repository or sends it to a developer. The TEMPLATE.yaml declares only benign tools so the recipe passes the dangerous-tool policy. The workflow.yaml assigns execute_command to an agent and adds approve: [execute_command]. When the victim runs the recipe without allow_dangerous_tools, the workflow installs the YAML-approved tool and the agent runs the attacker's shell commands, which steal environment variables, SSH keys and LLM API keys and open a reverse shell.

Weaknesses (CWE)

CWE-78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')Primary CWE-863Incorrect AuthorizationPrimary CWE-94Improper Control of Generation of Code ('Code Injection')Primary CWE-78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')CWE-863Incorrect Authorization CWE-94Improper Control of Generation of Code ('Code Injection')

CWE-78 — Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.

[Architecture and Design] If at all possible, use library calls rather than external processes to recreate the desired functionality.
[Architecture and Design, Operation] Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.