PT-2026-53149 · Pypi · Praisonai

Published

2026-06-18

·

Updated

2026-06-18

CVSS v3.1

7.8

High

VectorAV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

PraisonAI recipe.run stream() skips dangerous-tool policy enforcement

Summary

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:
python
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:
python
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:
text
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:
bash
python3 poc/pov prai cand 012 stream policy bypass.py
Expected output includes:
json
{
 "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.

Impact

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.

Suggested Fix

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.

Fix

Protection Mechanism Failure

Incorrect Authorization

OS Command Injection

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-693CWE-863CWE-78

Related Identifiers

GHSA-V847-HXXW-3PXG

Affected Products

Praisonai