{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.87"
            },
            {
              "fixed": "4.6.61"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-78",
      "CWE-863",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:26:57Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPraisonAI 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`.\n\nFor 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.\n\nAs 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.\n\nThe local PoV uses a harmless `printf` canary and explicitly unsets `PRAISONAI_AUTO_APPROVE`.\n\n## Technical Details\n\n`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`.\n\nThe steps workflow execution path is separate:\n\n1. `_execute_steps_workflow()` parses the workflow file with `YAMLWorkflowParser`.\n2. `YAMLWorkflowParser` resolves `agents.*.tools`.\n3. The same parser reads top-level `approve:` and stores it on `workflow.approve_tools`.\n4. `Workflow.start()` calls `set_yaml_approved_tools(approve_tools)`.\n5. The approval registry treats YAML-approved tools as approved.\n\n`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.\n\n### Why This Is Not Intended Behavior\n\nYAML `approve:` is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.\n\nThe 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.\n\nThis conflicts with the documented safety model:\n\n- PraisonAI\u0027s approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.\n- The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.\n- Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.\n- Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.\n\nA control recipe that declares `requires.tools: [execute_command]` is denied with:\n\n```text\nTool \u0027execute_command\u0027 is denied by default. Use allow_dangerous_tools=True to override.\n```\n\nThe bypass recipe uses the same tool but omits it from `requires.tools`; it passes policy and reaches the recipe runner\u0027s dry-run state.\n\n## PoV\n\nRun:\n\n```bash\npython3 poc/poc.py\n```\n\nExpected output:\n\n```json\n{\n  \"ok\": true,\n  \"control_policy\": \"Tool \u0027execute_command\u0027 is denied by default. Use allow_dangerous_tools=True to override.\",\n  \"control_recipe_status\": \"policy_denied\",\n  \"bypass_policy\": null,\n  \"bypass_recipe_dry_run_status\": \"dry_run\",\n  \"workflow_approve_tools\": [\n    \"execute_command\"\n  ],\n  \"runner_tool_names\": [\n    \"execute_command\"\n  ],\n  \"command_stdout\": \"poc\",\n  \"operator_env_auto_approve\": null\n}\n```\n\nThe PoV creates two temporary recipes:\n\n1. A control recipe with `TEMPLATE.yaml requires.tools: [execute_command]`. `recipe.run()` returns `policy_denied`.\n2. 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.\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nIf 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`.\n\nSuccessful 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.\n\nThis 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.\n\nThe 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.\n\n### Severity\n\nSuggested severity: High.\n\n## Suggested Fix\n\nNormalize and validate the actual workflow tool graph before recipe execution:\n\n- Parse the selected workflow file before or during `_check_tool_policy()`.\n- Include `workflow.yaml agents.*.tools`, `roles.*.tools`, included recipes, and other workflow-resolved tool lists in the dangerous-tool policy.\n- Treat `approve:` as an operator-supplied approval policy, not a recipe-controlled bypass of the recipe-level dangerous-tool gate.\n- 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.\n- Add regression tests for:\n  - dangerous tool in `TEMPLATE.yaml requires.tools` is denied;\n  - dangerous tool in `workflow.yaml agents.*.tools` is also denied;\n  - `approve: [execute_command]` does not bypass the recipe policy;\n  - `allow_dangerous_tools=True` keeps the intended opt-in behavior.\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `praisonai`\n- Components:\n  - `src/praisonai/praisonai/recipe/core.py`\n  - `src/praisonai/praisonai/recipe/models.py`\n  - `src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py`\n  - `src/praisonai-agents/praisonaiagents/workflows/workflows.py`\n  - `src/praisonai-agents/praisonaiagents/approval/registry.py`\n\nValidated affected:\n\n- current main `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- `v4.6.57`\n- `v4.6.56`\n- `v4.6.10`\n- `v4.6.9`\n- `v4.5.128`\n- `v4.5.120`\n- `v4.5.96`\n- `v4.5.87`\n\nSuggested affected range: `\u003e= 4.5.87, \u003c= 4.6.57`.\n\nPyPI lists `PraisonAI 4.6.57` as the latest release on 2026-06-13.\n\nEarlier 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.\n\n## Advisory History\n\nChecked 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.",
  "id": "GHSA-7qw2-w5rc-37x2",
  "modified": "2026-06-18T14:26:57Z",
  "published": "2026-06-18T14:26:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI recipe workflow policy can be bypassed by declaring and YAML-approving dangerous tools outside TEMPLATE.yaml"
}