Summary
PraisonAI recipes could bypass dangerous-tool controls and cause a workflow to approve a command-execution tool without the caller explicitly enabling it. An untrusted recipe could therefore execute operating-system commands when steps-based workflow execution processed attacker-controlled tool declarations and approvals.
PraisonAI recipes could bypass dangerous-tool controls and cause a workflow to approve a command-execution tool without the caller explicitly enabling it. An untrusted recipe could therefore execute operating-system commands when steps-based workflow execution processed attacker-controlled tool declarations and approvals.
Affected context
The issue affects PraisonAI recipe execution in versions 4.5.87 through versions before 4.6.61 when steps-based recipes use YAML workflow definitions. The risk arises when tool restrictions are checked only against TEMPLATE.yaml requires.tools while workflow.yaml can independently declare agent-level tools and top-level approvals. Deployments that execute untrusted or insufficiently reviewed recipes are particularly exposed.
The issue affects PraisonAI recipe execution in versions 4.5.87 through versions before 4.6.61 when steps-based recipes use YAML workflow definitions. The risk arises when tool restrictions are checked only against TEMPLATE.yaml requires.tools while workflow.yaml can independently declare agent-level tools and top-level approvals. Deployments that execute untrusted or insufficiently reviewed recipes are particularly exposed.
Exploit preconditions
- Attack surface: PraisonAI recipe and workflow configuration processing
- Required access: Ability to supply, modify, or cause execution of an untrusted recipe
- Trigger point: Workflow startup when YAML-defined tools and approvals are installed
- Why exploitation is possible: Dangerous-tool policy enforcement does not consistently cover tools introduced through the workflow execution path, allowing a recipe-level approval to authorize a command-execution capability without the caller's explicit opt-in
- Attack surface: PraisonAI recipe and workflow configuration processing
- Required access: Ability to supply, modify, or cause execution of an untrusted recipe
- Trigger point: Workflow startup when YAML-defined tools and approvals are installed
- Why exploitation is possible: Dangerous-tool policy enforcement does not consistently cover tools introduced through the workflow execution path, allowing a recipe-level approval to authorize a command-execution capability without the caller's explicit opt-in
Why this happens
The underlying flaw is an authorization boundary failure combined with command-execution exposure. PraisonAI validates dangerous tools using one configuration source, but the workflow parser and startup logic accept additional tool declarations and approvals from another source. This allows untrusted recipe data to influence authorization decisions for a shell-capable tool. The behavior maps primarily to CWE-78, OS command injection, and is also related to CWE-863, incorrect authorization, and CWE-94 where attacker-controlled workflow configuration enables executable behavior.
The underlying flaw is an authorization boundary failure combined with command-execution exposure. PraisonAI validates dangerous tools using one configuration source, but the workflow parser and startup logic accept additional tool declarations and approvals from another source. This allows untrusted recipe data to influence authorization decisions for a shell-capable tool. The behavior maps primarily to CWE-78, OS command injection, and is also related to CWE-863, incorrect authorization, and CWE-94 where attacker-controlled workflow configuration enables executable behavior.
Potential impact
- An attacker could execute operating-system commands in the PraisonAI runtime
- The application process and its accessible data could be compromised
- Credentials, files, or service tokens available to the process may be exposed
- The host or connected services could be altered or used for lateral movement
- Automated workflows could be abused for data manipulation or supply-chain impact
- An attacker could execute operating-system commands in the PraisonAI runtime
- The application process and its accessible data could be compromised
- Credentials, files, or service tokens available to the process may be exposed
- The host or connected services could be altered or used for lateral movement
- Automated workflows could be abused for data manipulation or supply-chain impact
General mitigation guidance
Mitigation generally focuses on enforcing dangerous-tool authorization at the
final execution boundary rather than relying on a single recipe metadata file.
Common defensive patterns include:
- Require explicit caller authorization for every dangerous tool, regardless of where it is declared
- Treat recipe and workflow YAML as untrusted input and do not allow it to grant elevated capabilities
- Maintain one canonical, validated tool policy across template parsing, workflow parsing, approval, and execution
- Use allowlists for permitted tools and deny shell or command-execution capabilities by default
- Run recipe workers with least-privilege identities, isolated filesystems, restricted network access, and minimal secret exposure
- Separate workflow authorship from runtime approval and require review or policy enforcement for privileged tools
Mitigation generally focuses on enforcing dangerous-tool authorization at the
final execution boundary rather than relying on a single recipe metadata file.
Common defensive patterns include:
- Require explicit caller authorization for every dangerous tool, regardless of where it is declared
- Treat recipe and workflow YAML as untrusted input and do not allow it to grant elevated capabilities
- Maintain one canonical, validated tool policy across template parsing, workflow parsing, approval, and execution
- Use allowlists for permitted tools and deny shell or command-execution capabilities by default
- Run recipe workers with least-privilege identities, isolated filesystems, restricted network access, and minimal secret exposure
- Separate workflow authorship from runtime approval and require review or policy enforcement for privileged tools
How teams detect issues like this
Detection can include:
- Static analysis for dangerous-tool checks that examine only one configuration source
- Code review of parser, approval, and execution paths for inconsistent authorization decisions
- Tests confirming that workflow-defined tools cannot bypass caller-level dangerous-tool settings
- Policy checks that reject shell-capable tools in untrusted recipes or require explicit signed approval
- Runtime logging of tool declarations, approval sources, caller authorization, and command-execution events
- Automated security review tools that identify command-execution APIs and authorization gaps
Detection can include:
- Static analysis for dangerous-tool checks that examine only one configuration source
- Code review of parser, approval, and execution paths for inconsistent authorization decisions
- Tests confirming that workflow-defined tools cannot bypass caller-level dangerous-tool settings
- Policy checks that reject shell-capable tools in untrusted recipes or require explicit signed approval
- Runtime logging of tool declarations, approval sources, caller authorization, and command-execution events
- Automated security review tools that identify command-execution APIs and authorization gaps
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
