GHSA-7QW2-W5RC-37X2

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.

The local PoV uses a harmless printf canary and explicitly unsets PRAISONAI_AUTO_APPROVE.

Technical Details

recipe.run() checks the recipe policy unless options["allow_dangerous_tools"] is true. _check_tool_policy() gets the required tool list from recipe_config.get_required_tools(), which is backed by TEMPLATE.yaml requires.tools.

The steps workflow execution path is separate:

1. _execute_steps_workflow() parses the workflow file with YAMLWorkflowParser.
2. YAMLWorkflowParser resolves agents.*.tools.
3. The same parser reads top-level approve: and stores it on workflow.approve_tools.
4. Workflow.start() calls set_yaml_approved_tools(approve_tools).
5. The approval registry treats YAML-approved tools as approved.

execute_command is listed as a default dangerous tool with critical risk and is decorated with @require_approval(risk_level="critical"). The policy gap is that recipe-level dangerous-tool enforcement does not inspect the workflow file that actually supplies and approves the tool.

Why This Is Not Intended Behavior

YAML approve: is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.

The unintended behavior is that the recipe dangerous-tool policy exposes an operator-facing explicit override, allow_dangerous_tools=True, but a recipe can avoid that policy by moving the dangerous tool declaration from TEMPLATE.yaml requires.tools into the steps workflow. The recipe still runs through the standard recipe runner path, and the same workflow can self-approve the critical tool.

This conflicts with the documented safety model:

• PraisonAI's approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.
• The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.
• Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.
• Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.

A control recipe that declares requires.tools: [execute_command] is denied with:

Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.

The bypass recipe uses the same tool but omits it from requires.tools; it passes policy and reaches the recipe runner's dry-run state.

PoV

Run:

python3 poc/poc.py

Expected output:

{
  "ok": true,
  "control_policy": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
  "control_recipe_status": "policy_denied",
  "bypass_policy": null,
  "bypass_recipe_dry_run_status": "dry_run",
  "workflow_approve_tools": [
    "execute_command"
  ],
  "runner_tool_names": [
    "execute_command"
  ],
  "command_stdout": "poc",
  "operator_env_auto_approve": null
}

The PoV creates two temporary recipes:

1. A control recipe with TEMPLATE.yaml requires.tools: [execute_command]. recipe.run() returns policy_denied.
2. A bypass recipe with no dangerous tools in TEMPLATE.yaml, but with workflow.yaml declaring execute_command under an agent and approve: [execute_command]. recipe.run(..., dry_run=True) reaches dry_run, and the same parser/approval context permits a harmless `printf poc.

PoC

The PoV section above contains the local reproduction command, input, and decisive output.

Severity

Suggested severity: High.

Affected Package/Versions

• Repository: MervinPraison/PraisonAI
• Package: praisonai
• Components:
  • src/praisonai/praisonai/recipe/core.py
  • src/praisonai/praisonai/recipe/models.py
  • src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py
  • src/praisonai-agents/praisonaiagents/workflows/workflows.py
  • src/praisonai-agents/praisonaiagents/approval/registry.py

Validated affected:

• current main 2f9677abb2ea68eab864ee8b6a828fd0141612e1
• v4.6.57
• v4.6.56
• v4.6.10
• v4.6.9
• v4.5.128
• v4.5.120
• v4.5.96
• v4.5.87

Suggested affected range: >= 4.5.87, <= 4.6.57.

PyPI lists PraisonAI 4.6.57 as the latest release on 2026-06-13.

Earlier tested tags through v4.5.85 failed in this source checkout before the tested workflow path due an unrelated praisonaiagents.output.models import error. They are not claimed fixed or unaffected.

Advisory History

Checked visible PraisonAI advisories and prior submissions for the same root cause, affected entrypoint, and exploit preconditions. No exact duplicate is identified in this report text. Adjacent advisories, where relevant, are listed in References or discussed above.

If an operator runs an untrusted recipe, or exposes the recipe runner to users who can choose recipe names/URIs, the recipe can self-authorize a default-denied critical shell tool without the operator setting allow_dangerous_tools=True.

Successful exploitation lets the workflow run execute_command with the privileges of the PraisonAI process if the agent reaches the tool call. The exact trigger depends on the workflow and model/tool-call path, but the policy boundary is already bypassed before execution.

This can affect both local CLI use and HTTP recipe-runner deployments. The HTTP recipe runner defaults to localhost/no-auth and requires auth for non-localhost binding, so this report uses local/UI-required severity rather than claiming an unauthenticated network RCE by default.

The local HTTP sidecar documentation also frames the sidecar as a localhost REST API for local/polyglot integration. If a deployment exposes that API to authenticated users who can choose recipe names or URIs, the same policy bypass can become an authenticated remote recipe-execution issue, but that is not the default severity claim.

Untrusted input reaches a shell command, allowing arbitrary commands to run on the host. Typical impact: code execution in the application's environment.

GHSA-7QW2-W5RC-37X2 has a CVSS score of 7.8 (High). The vector is requires local access, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.6.61); upgrading removes the vulnerable code path.

Kodem intelligence

Normalize and validate the actual workflow tool graph before recipe execution:

• Parse the selected workflow file before or during _check_tool_policy().
• Include workflow.yaml agents.*.tools, roles.*.tools, included recipes, and other workflow-resolved tool lists in the dangerous-tool policy.
• Treat approve: as an operator-supplied approval policy, not a recipe-controlled bypass of the recipe-level dangerous-tool gate.
• If approve: remains recipe-controlled, ignore dangerous/default-denied tool entries unless the caller passed allow_dangerous_tools=True or an explicit external policy allowed that exact tool.
• Add regression tests for:
  • dangerous tool in TEMPLATE.yaml requires.tools is denied;
  • dangerous tool in workflow.yaml agents.*.tools is also denied;
  • approve: [execute_command] does not bypass the recipe policy;
  • allow_dangerous_tools=True keeps the intended opt-in behavior.

1. What is GHSA-7QW2-W5RC-37X2? GHSA-7QW2-W5RC-37X2 is a high-severity OS command injection vulnerability in praisonai (pip), affecting versions >= 4.5.87, < 4.6.61. It is fixed in 4.6.61. Untrusted input reaches a shell command, allowing arbitrary commands to run on the host.
2. How severe is GHSA-7QW2-W5RC-37X2? GHSA-7QW2-W5RC-37X2 has a CVSS score of 7.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of praisonai are affected by GHSA-7QW2-W5RC-37X2? praisonai (pip) versions >= 4.5.87, < 4.6.61 is affected.
4. Is there a fix for GHSA-7QW2-W5RC-37X2? Yes. GHSA-7QW2-W5RC-37X2 is fixed in 4.6.61. Upgrade to this version or later.
5. Is GHSA-7QW2-W5RC-37X2 exploitable, and should I be worried? Whether GHSA-7QW2-W5RC-37X2 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-7QW2-W5RC-37X2 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-7QW2-W5RC-37X2? Upgrade praisonai to 4.6.61 or later.