Summary
PraisonAI's streaming recipe execution path can bypass the policy check that normally blocks dangerous tools such as execute_command.
A caller able to run a crafted or trusted recipe through recipe.run_stream() may therefore trigger command execution without explicitly enabling dangerous tools, depending on the deployment's access controls.
PraisonAI's streaming recipe execution path can bypass the policy check that normally blocks dangerous tools such as execute_command.
A caller able to run a crafted or trusted recipe through recipe.run_stream() may therefore trigger command execution without explicitly enabling dangerous tools, depending on the deployment's access controls.
Affected context
The issue occurs in PraisonAI versions where recipe.run_stream() loads a recipe and checks dependencies but invokes _execute_recipe() without applying the dangerous-tool policy enforced by the ordinary recipe.run() path. It is relevant when recipes can declare tools such as execute_command and an untrusted or insufficiently trusted caller can select, submit, or influence recipes executed through the streaming interface.
The issue occurs in PraisonAI versions where recipe.run_stream() loads a recipe and checks dependencies but invokes _execute_recipe() without applying the dangerous-tool policy enforced by the ordinary recipe.run() path. It is relevant when recipes can declare tools such as execute_command and an untrusted or insufficiently trusted caller can select, submit, or influence recipes executed through the streaming interface.
Exploit preconditions
- Attack surface: PraisonAI recipe execution through the streaming
run_stream()interface - Required access: Permission to invoke the streaming recipe path and provide or select a recipe containing a dangerous tool
- Trigger point: Execution of a recipe after dependency checks but before the missing dangerous-tool authorization check
- Why exploitation is possible: The streaming path reaches the execution engine without enforcing the policy that requires explicit authorization for dangerous tools
- Attack surface: PraisonAI recipe execution through the streaming
run_stream()interface - Required access: Permission to invoke the streaming recipe path and provide or select a recipe containing a dangerous tool
- Trigger point: Execution of a recipe after dependency checks but before the missing dangerous-tool authorization check
- Why exploitation is possible: The streaming path reaches the execution engine without enforcing the policy that requires explicit authorization for dangerous tools
Why this happens
The underlying defect is an authorization-check omission between two functionally equivalent execution paths. Although recipe.run() invokes _check_tool_policy() before execution, recipe.run_stream() proceeds to _execute_recipe() without applying the same control, allowing a recipe's declared dangerous tool to be executed despite the caller's default-denied setting. This maps primarily to CWE-78: Improper Neutralization of Special Elements used in an OS Command, with CWE-863: Incorrect Authorization and CWE-693: Protection Mechanism Failure describing the missing enforcement and bypassed security control.
The underlying defect is an authorization-check omission between two functionally equivalent execution paths. Although recipe.run() invokes _check_tool_policy() before execution, recipe.run_stream() proceeds to _execute_recipe() without applying the same control, allowing a recipe's declared dangerous tool to be executed despite the caller's default-denied setting. This maps primarily to CWE-78: Improper Neutralization of Special Elements used in an OS Command, with CWE-863: Incorrect Authorization and CWE-693: Protection Mechanism Failure describing the missing enforcement and bypassed security control.
Potential impact
- An attacker may execute arbitrary operating-system commands in the PraisonAI process environment.
- The application could experience data theft, modification, or destruction.
- Credentials, tokens, or other secrets accessible to the process could be exposed.
- The host or surrounding services could be affected according to the process's privileges and network access.
- An attacker may execute arbitrary operating-system commands in the PraisonAI process environment.
- The application could experience data theft, modification, or destruction.
- Credentials, tokens, or other secrets accessible to the process could be exposed.
- The host or surrounding services could be affected according to the process's privileges and network access.
General mitigation guidance
Mitigation generally focuses on enforcing identical authorization controls across every recipe execution interface.
Common defensive patterns include:
- Apply the dangerous-tool policy check immediately before execution in both streaming and non-streaming paths.
- Treat dangerous tools as denied by default and require an explicit, authenticated authorization decision.
- Centralize tool-policy enforcement so alternate APIs cannot bypass it.
- Use allowlists for executable tools and restrict command capabilities where possible.
- Run recipe workers with least privilege, isolated filesystems, limited network access, and narrowly scoped secrets.
- Reduce input trust by validating recipe metadata and preventing untrusted callers from selecting or modifying executable tool declarations.
Mitigation generally focuses on enforcing identical authorization controls across every recipe execution interface.
Common defensive patterns include:
- Apply the dangerous-tool policy check immediately before execution in both streaming and non-streaming paths.
- Treat dangerous tools as denied by default and require an explicit, authenticated authorization decision.
- Centralize tool-policy enforcement so alternate APIs cannot bypass it.
- Use allowlists for executable tools and restrict command capabilities where possible.
- Run recipe workers with least privilege, isolated filesystems, limited network access, and narrowly scoped secrets.
- Reduce input trust by validating recipe metadata and preventing untrusted callers from selecting or modifying executable tool declarations.
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis that compares security checks across equivalent execution paths.
- Code review searches for direct calls to execution engines that are not preceded by authorization or tool-policy enforcement.
- Tests verifying that every recipe API, including streaming and asynchronous variants, rejects dangerous tools by default.
- Policy checks requiring centralized authorization wrappers around command-execution capabilities.
- Runtime telemetry for dangerous-tool invocation, including the caller, recipe, authorization decision, and execution path.
Automated code-review and security-analysis tools may help detect inconsistent enforcement between related APIs.
Organizations can identify this class of issue through:
- Static analysis that compares security checks across equivalent execution paths.
- Code review searches for direct calls to execution engines that are not preceded by authorization or tool-policy enforcement.
- Tests verifying that every recipe API, including streaming and asynchronous variants, rejects dangerous tools by default.
- Policy checks requiring centralized authorization wrappers around command-execution capabilities.
- Runtime telemetry for dangerous-tool invocation, including the caller, recipe, authorization decision, and execution path.
Automated code-review and security-analysis tools may help detect inconsistent enforcement between related APIs.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
