Vulnerability-Lookup

CVE-2026-57142 (GCVE-0-2026-57142)

Vulnerability from cvelistv5 – Published: 2026-10-23 12:07 – Updated: 2026-10-23 12:07

Title

PraisonAI recipe workflow policy can be bypassed by declaring and YAML-approving dangerous tools outside TEMPLATE.yaml

Summary

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.

Severity

7.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE

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

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7761 records in the last 180 days details

References

1 reference

URL	Tags
https://github.com/MervinPraison/PraisonAI/securi…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version	CPE status
MervinPraison	PraisonAI	Affected: >= 4.5.87, < 4.6.61	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "PraisonAI",
          "vendor": "MervinPraison",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.5.87, \u003c 4.6.61"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "HIGH",
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-78",
              "description": "CWE-78: Improper Neutralization of Special Elements used in an OS Command (\u0027OS Command Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-94",
              "description": "CWE-94: Improper Control of Generation of Code (\u0027Code Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-863",
              "description": "CWE-863: Incorrect Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-23T12:07:46.547Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2"
        }
      ],
      "source": {
        "advisory": "GHSA-7qw2-w5rc-37x2",
        "discovery": "UNKNOWN"
      },
      "title": "PraisonAI recipe workflow policy can be bypassed by declaring and YAML-approving dangerous tools outside TEMPLATE.yaml"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-57142",
    "datePublished": "2026-10-23T12:07:46.547Z",
    "dateReserved": "2026-06-24T01:45:48.697Z",
    "dateUpdated": "2026-10-23T12:07:46.547Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-57142",
      "date": "2026-10-25",
      "epss": "0.00146",
      "percentile": "0.03816"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "PraisonAI",
                "vendor": "MervinPraison",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003e= 4.5.87, \u003c 4.6.61"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "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."
          }
        ],
        "id": "CVE-2026-57142",
        "lastModified": "2026-10-23T13:17:11.330",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "REQUIRED",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-10-23T13:17:11.210",
        "references": [
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-78"
              },
              {
                "lang": "en",
                "value": "CWE-94"
              },
              {
                "lang": "en",
                "value": "CWE-863"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Primary"
          }
        ]
      }
    }
  }
}

FKIE_CVE-2026-57142

Vulnerability from fkie_nvd - Published: 2026-10-23 13:17 - Updated: 2026-10-23 13:17

Severity

7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "PraisonAI",
          "vendor": "MervinPraison",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.5.87, \u003c 4.6.61"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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."
    }
  ],
  "id": "CVE-2026-57142",
  "lastModified": "2026-10-23T13:17:11.330",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-10-23T13:17:11.210",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-78"
        },
        {
          "lang": "en",
          "value": "CWE-94"
        },
        {
          "lang": "en",
          "value": "CWE-863"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

GHSA-7QW2-W5RC-37X2

Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-07-20 21:28

Summary

PraisonAI recipe workflow policy can be bypassed by declaring and YAML-approving dangerous tools outside TEMPLATE.yaml

Details

Summary

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:

_execute_steps_workflow() parses the workflow file with YAMLWorkflowParser.
YAMLWorkflowParser resolves agents.*.tools.
The same parser reads top-level approve: and stores it on workflow.approve_tools.
Workflow.start() calls set_yaml_approved_tools(approve_tools).
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:

A control recipe with TEMPLATE.yaml requires.tools: [execute_command]. recipe.run() returns policy_denied.
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.

Impact

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.

Severity

Suggested severity: High.

Suggested Fix

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.

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.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.87"
            },
            {
              "fixed": "4.6.61"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57142"
  ],
  "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-07-20T21:28:14Z",
  "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"
}

PYSEC-2026-3505

Vulnerability from pysec - Published: 2026-07-23 11:41 - Updated: 2026-07-23 14:32

Details

Summary

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

Technical Details

The steps workflow execution path is separate:

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

Why This Is Not Intended Behavior

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

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:

A control recipe with TEMPLATE.yaml requires.tools: [execute_command]. recipe.run() returns policy_denied.
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.

Impact

Severity

Suggested severity: High.

Suggested Fix

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.

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.

Advisory History

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Impacted products

Name	purl
praisonai	pkg:pypi/praisonai

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai",
        "purl": "pkg:pypi/praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.87"
            },
            {
              "fixed": "4.6.61"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "4.5.100",
        "4.5.101",
        "4.5.102",
        "4.5.103",
        "4.5.104",
        "4.5.105",
        "4.5.106",
        "4.5.107",
        "4.5.108",
        "4.5.109",
        "4.5.110",
        "4.5.111",
        "4.5.112",
        "4.5.113",
        "4.5.114",
        "4.5.115",
        "4.5.117",
        "4.5.118",
        "4.5.119",
        "4.5.120",
        "4.5.121",
        "4.5.122",
        "4.5.123",
        "4.5.124",
        "4.5.125",
        "4.5.126",
        "4.5.127",
        "4.5.128",
        "4.5.129",
        "4.5.130",
        "4.5.131",
        "4.5.132",
        "4.5.133",
        "4.5.134",
        "4.5.135",
        "4.5.136",
        "4.5.137",
        "4.5.139",
        "4.5.140",
        "4.5.143",
        "4.5.144",
        "4.5.145",
        "4.5.149",
        "4.5.87",
        "4.5.88",
        "4.5.89",
        "4.5.90",
        "4.5.93",
        "4.5.94",
        "4.5.95",
        "4.5.96",
        "4.5.97",
        "4.5.98",
        "4.6.10",
        "4.6.11",
        "4.6.12",
        "4.6.13",
        "4.6.14",
        "4.6.15",
        "4.6.16",
        "4.6.18",
        "4.6.19",
        "4.6.20",
        "4.6.21",
        "4.6.22",
        "4.6.23",
        "4.6.24",
        "4.6.25",
        "4.6.26",
        "4.6.27",
        "4.6.28",
        "4.6.29",
        "4.6.30",
        "4.6.31",
        "4.6.32",
        "4.6.33",
        "4.6.34",
        "4.6.35",
        "4.6.36",
        "4.6.37",
        "4.6.38",
        "4.6.39",
        "4.6.40",
        "4.6.41",
        "4.6.42",
        "4.6.43",
        "4.6.44",
        "4.6.45",
        "4.6.46",
        "4.6.47",
        "4.6.48",
        "4.6.50",
        "4.6.51",
        "4.6.52",
        "4.6.53",
        "4.6.54",
        "4.6.55",
        "4.6.56",
        "4.6.57",
        "4.6.58",
        "4.6.59",
        "4.6.60",
        "4.6.9"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57142",
    "GHSA-7qw2-w5rc-37x2"
  ],
  "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": "PYSEC-2026-3505",
  "modified": "2026-07-23T14:32:29.800118Z",
  "published": "2026-07-23T11:41:42.894320Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/praisonai"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-7qw2-w5rc-37x2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57142"
    }
  ],
  "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"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-57142 (GCVE-0-2026-57142)

FKIE_CVE-2026-57142

GHSA-7QW2-W5RC-37X2

Summary

Technical Details

Why This Is Not Intended Behavior

PoV

PoC

Impact

Severity

Suggested Fix

Affected Package/Versions

Advisory History

PYSEC-2026-3505

Summary

Technical Details

Why This Is Not Intended Behavior

PoV

PoC

Impact

Severity

Suggested Fix

Affected Package/Versions

Advisory History

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour