{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/praisonai--4.5.87--4.6.61/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["PraisonAI (\u003e= 4.5.87, \u003c 4.6.61)"],"_cs_severities":["high"],"_cs_tags":["application-vulnerability","policy-bypass","remote-code-execution","praisonai","python"],"_cs_type":"advisory","_cs_vendors":["MervinPraison"],"content_html":"\u003cp\u003eA critical policy bypass vulnerability affects PraisonAI, a recipe execution platform, specifically versions \u003ccode\u003ev4.5.87\u003c/code\u003e through \u003ccode\u003ev4.6.57\u003c/code\u003e. The platform's security model intends to block \u0026quot;dangerous tools\u0026quot; (e.g., \u003ccode\u003eexecute_command\u003c/code\u003e) unless an operator explicitly allows them via \u003ccode\u003eallow_dangerous_tools=True\u003c/code\u003e. However, an untrusted recipe can circumvent this control. By crafting a \u003ccode\u003eworkflow.yaml\u003c/code\u003e that declares a default-denied tool within an agent's \u003ccode\u003etools\u003c/code\u003e section and simultaneously using a top-level \u003ccode\u003eapprove:\u003c/code\u003e directive, the recipe can effectively self-approve the dangerous tool. This bypasses the initial security policy that only checks \u003ccode\u003eTEMPLATE.yaml requires.tools\u003c/code\u003e, enabling the recipe to execute arbitrary commands without operator consent. The vulnerability affects both local CLI usage and HTTP recipe-runner deployments, with potentially higher severity if exposed to authenticated users.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eAttacker crafts malicious PraisonAI recipe\u003c/strong\u003e: The attacker prepares a recipe consisting of a \u003ccode\u003eworkflow.yaml\u003c/code\u003e that declares a default-denied critical tool (e.g., \u003ccode\u003eexecute_command\u003c/code\u003e) under an agent's \u003ccode\u003etools\u003c/code\u003e section and includes \u003ccode\u003eapprove: [execute_command]\u003c/code\u003e at the top level, while ensuring the \u003ccode\u003eTEMPLATE.yaml requires.tools\u003c/code\u003e section does not list any dangerous tools.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOperator runs untrusted recipe\u003c/strong\u003e: An operator or user runs the attacker-controlled recipe through the PraisonAI local CLI or an exposed HTTP recipe runner, critically without specifying \u003ccode\u003eallow_dangerous_tools=True\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial policy check bypassed\u003c/strong\u003e: \u003ccode\u003ePraisonAI\u003c/code\u003e's \u003ccode\u003e_check_tool_policy()\u003c/code\u003e function inspects only the \u003ccode\u003eTEMPLATE.yaml requires.tools\u003c/code\u003e list. Since the malicious \u003ccode\u003eworkflow.yaml\u003c/code\u003e avoids listing dangerous tools there, the recipe passes this initial security gate.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e\u003ccode\u003eYAMLWorkflowParser\u003c/code\u003e processes \u003ccode\u003eworkflow.yaml\u003c/code\u003e\u003c/strong\u003e: During the \u003ccode\u003e_execute_steps_workflow()\u003c/code\u003e phase, \u003ccode\u003eYAMLWorkflowParser\u003c/code\u003e parses the \u003ccode\u003eworkflow.yaml\u003c/code\u003e, resolving agent-level \u003ccode\u003etools:\u003c/code\u003e declarations and extracting the top-level \u003ccode\u003eapprove:\u003c/code\u003e directives.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWorkflow self-approves dangerous tools\u003c/strong\u003e: The \u003ccode\u003eWorkflow.start()\u003c/code\u003e method invokes \u003ccode\u003eset_yaml_approved_tools()\u003c/code\u003e, which registers the tools specified in the \u003ccode\u003eapprove:\u003c/code\u003e directive (including the dangerous \u003ccode\u003eexecute_command\u003c/code\u003e) within the application's approval context, effectively self-approving them.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAgent executes dangerous command\u003c/strong\u003e: When the PraisonAI agent within the workflow attempts to utilize the \u003ccode\u003eexecute_command\u003c/code\u003e tool, it is treated as pre-approved due to the bypass, allowing the agent to proceed with its execution.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eArbitrary command execution\u003c/strong\u003e: The \u003ccode\u003eexecute_command\u003c/code\u003e tool then executes arbitrary operating system commands specified by the attacker within the \u003ccode\u003eworkflow.yaml\u003c/code\u003e, inheriting the privileges of the underlying PraisonAI process.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact\u003c/strong\u003e: This unapproved command execution can lead to remote code execution, data exfiltration, system compromise, or facilitate further lateral movement within the compromised environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis policy bypass allows an untrusted recipe to execute arbitrary commands with the privileges of the PraisonAI process. If an operator runs such a recipe, or if a PraisonAI HTTP recipe runner is exposed to users who can choose recipe names or URIs, successful exploitation can lead to full system compromise. The exact trigger for command execution depends on the specific workflow and model/tool-call path, but the core policy boundary is breached before execution. This impacts both local CLI usage of PraisonAI and deployments utilizing the HTTP recipe runner, potentially escalating to an authenticated remote execution issue if the API is accessible.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePatch \u003ccode\u003ePraisonAI\u003c/code\u003e\u003c/strong\u003e: Upgrade \u003ccode\u003ePraisonAI\u003c/code\u003e to version \u003ccode\u003e4.6.61\u003c/code\u003e or later immediately to address the vulnerability described in the GHSA advisory.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMonitor \u003ccode\u003eprocess_creation\u003c/code\u003e logs\u003c/strong\u003e: Deploy the Sigma rules provided in this brief to detect suspicious command execution originating from \u003ccode\u003ePraisonAI\u003c/code\u003e processes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEnable Sysmon logging\u003c/strong\u003e: Ensure Sysmon process creation and command line logging (Event ID 1) is enabled on all Windows systems running PraisonAI to facilitate detection of spawned shell processes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-06-18T15:01:53Z","date_published":"2026-06-18T15:01:53Z","id":"https://feed.craftedsignal.io/briefs/2026-06-praisonai-policy-bypass/","summary":"A policy bypass vulnerability in PraisonAI (CVE-NONE) allows untrusted recipes to self-approve and execute default-denied critical shell tools, such as `execute_command`, by declaring them in `workflow.yaml` instead of `TEMPLATE.yaml requires.tools`, leading to arbitrary command execution with the privileges of the PraisonAI process.","title":"PraisonAI Recipe Policy Bypass via YAML Workflow Approval","url":"https://feed.craftedsignal.io/briefs/2026-06-praisonai-policy-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - PraisonAI (\u003e= 4.5.87, \u003c 4.6.61)","version":"https://jsonfeed.org/version/1.1"}