GHSA-V847-HXXW-3PXG

PraisonAI recipe.run_stream() skips dangerous-tool policy enforcement

PraisonAI recipe execution blocks default-denied dangerous tools unless the
caller explicitly passes allow_dangerous_tools=True. The normal recipe.run()
path enforces this with _check_tool_policy(). The streaming path,
recipe.run_stream(), loads the same recipe, checks dependencies, and then
calls _execute_recipe() without running the dangerous-tool policy check.

As a result, a recipe that honestly declares execute_command in
TEMPLATE.yaml requires.tools is denied by recipe.run(), but reaches the
execution engine through recipe.run_stream() with
allow_dangerous_tools=False.

The local PoV uses a harmless printf canary, explicitly unsets
PRAISONAI_AUTO_APPROVE, and avoids network access.

Affected Product

• Repository: MervinPraison/PraisonAI
• Package: praisonai
• Components:
  • src/praisonai/praisonai/recipe/core.py
  • src/praisonai/praisonai/recipe/serve.py
  • src/praisonai/praisonai/cli/features/recipe.py
  • src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py
  • src/praisonai-agents/praisonaiagents/workflows/workflows.py

Validated affected:

• current main 2f9677abb2ea68eab864ee8b6a828fd0141612e1
  (v4.6.57-4-g2f9677ab)
• 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.

Root Cause

recipe.run() enforces the dangerous-tool gate:

if not options.get("allow_dangerous_tools", False):
    policy_error = _check_tool_policy(recipe_config)
    if policy_error:
        return RecipeResult(..., status=RecipeStatus.POLICY_DENIED, ...)

recipe.run_stream() has a sibling execution path. It loads the recipe and
checks dependencies, but then goes directly to execution:

recipe_config = _load_recipe(name, offline=options.get("offline", False))
...
output = _execute_recipe(recipe_config, merged_config, session_id, options)

There is no equivalent _check_tool_policy() call in run_stream() before
execution or before the dry-run shortcut.

The CLI exposes this path via praisonai recipe run <recipe> --stream, and the
recipe HTTP server exposes it as POST /v1/recipes/stream.

Why This Is Not Intended Behavior

The normal recipe path clearly treats declared dangerous tools as denied by
default. A control recipe with TEMPLATE.yaml requires.tools: [execute_command] returns:

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

That operator-facing override should not depend on whether the caller requests
streaming output. PraisonAI's own docs describe approval as requiring a human
or configured channel before risky tools run, describe security environment
variables as opt-in access for dangerous operations with secure defaults, and
describe policy controls as blocking dangerous operations.

This is distinct from the prior report PRAI-CAND-011:

• PRAI-CAND-011 covers workflow tool declarations that are omitted from
  TEMPLATE.yaml requires.tools.
• This report covers a sibling entrypoint that skips the policy check even when
  TEMPLATE.yaml correctly declares the dangerous tool.

It is also distinct from the published Recipe-server authentication fail-open
advisory. That advisory covers missing authentication secrets. This report
assumes the attacker has whatever access is already needed to invoke recipe
streaming and focuses on the missing dangerous-tool policy guard.

Local PoV

Run:

python3 poc/pov_prai_cand_012_stream_policy_bypass.py

Expected output includes:

{
  "ok": true,
  "policy_error": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
  "control_recipe_status": "policy_denied",
  "execution_reached": [
    {
      "recipe": "declared-dangerous-stream",
      "declared_required_tools": ["execute_command"],
      "allow_dangerous_tools": false
    }
  ],
  "workflow_approve_tools": ["execute_command"],
  "runner_tool_names": ["execute_command"],
  "command_stdout": "PRAI-CAND-012-CANARY",
  "operator_env_auto_approve": null
}

The PoV creates a temporary recipe that declares execute_command in
TEMPLATE.yaml requires.tools.

Control:

• recipe.run(..., options={"force": True}) returns policy_denied.

Bypass:

• recipe.run_stream(..., options={"force": True}) emits the executing
  event and reaches _execute_recipe() while allow_dangerous_tools remains
  false.
• The same recipe workflow resolves execute_command and preserves
  approve: [execute_command].
• With the workflow approval context installed, the resolved tool runs the
  harmless local command printf PRAI-CAND-012-CANARY.

The PoV monkey-patches _execute_recipe() only to prove that
run_stream() crosses the policy boundary without invoking an LLM. The command
canary is executed directly through the same resolved workflow tool and
approval context to keep the proof deterministic and local-only.

If an operator runs an untrusted recipe through streaming mode, or exposes the
recipe streaming API to users who can choose recipe names or URIs, the recipe
can reach execution with default-denied tools even though the caller did not
set allow_dangerous_tools=True.

If the workflow reaches the approved execute_command tool call, commands run
with the privileges of the PraisonAI process. The exact trigger depends on the
workflow and model/tool-call path, but the dangerous-tool policy boundary is
already bypassed before execution.

The HTTP recipe sidecar is documented as a localhost REST API with SSE
streaming and optional API-key/JWT authentication. This report does not claim
default unauthenticated network RCE. In authenticated or exposed sidecar
deployments where lower-trust users can invoke /v1/recipes/stream, the same
policy gap can become a remote recipe-execution issue.

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

GHSA-V847-HXXW-3PXG 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.59); upgrading removes the vulnerable code path.

Kodem intelligence

Centralize recipe preflight enforcement so every execution mode uses the same
guard:

1. Run _check_tool_policy(recipe_config) in run_stream() unless
   options["allow_dangerous_tools"] is true.
2. Perform that check before both dry-run and real execution, matching
   recipe.run().
3. Prefer a shared helper for dependency checks, dangerous-tool policy checks,
   and dry-run handling so future entrypoints cannot drift.
4. Add regression tests:
   • declared dangerous tool is denied by recipe.run();
   • the same declared dangerous tool is denied by recipe.run_stream();
   • allow_dangerous_tools=True preserves the intended opt-in behavior;
   • /v1/recipes/stream maps a policy denial to a non-success SSE event or
     equivalent HTTP failure.

1. What is GHSA-V847-HXXW-3PXG? GHSA-V847-HXXW-3PXG is a high-severity OS command injection vulnerability in praisonai (pip), affecting versions >= 4.5.87, <= 4.6.58. It is fixed in 4.6.59. Untrusted input reaches a shell command, allowing arbitrary commands to run on the host.
2. How severe is GHSA-V847-HXXW-3PXG? GHSA-V847-HXXW-3PXG 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-V847-HXXW-3PXG? praisonai (pip) versions >= 4.5.87, <= 4.6.58 is affected.
4. Is there a fix for GHSA-V847-HXXW-3PXG? Yes. GHSA-V847-HXXW-3PXG is fixed in 4.6.59. Upgrade to this version or later.
5. Is GHSA-V847-HXXW-3PXG exploitable, and should I be worried? Whether GHSA-V847-HXXW-3PXG 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-V847-HXXW-3PXG 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-V847-HXXW-3PXG? Upgrade praisonai to 4.6.59 or later.