How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

375,699

Total vulnerabilities in the database

CVE-2026-56838 — praisonai

Protection Mechanism Failure

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:

if not options.get(&quot;allow_dangerous_tools&quot;, 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(&quot;offline&quot;, 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 &#039;execute_command&#039; 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:

{
  &quot;ok&quot;: true,
  &quot;policy_error&quot;: &quot;Tool &#039;execute_command&#039; is denied by default. Use allow_dangerous_tools=True to override.&quot;,
  &quot;control_recipe_status&quot;: &quot;policy_denied&quot;,
  &quot;execution_reached&quot;: [
    {
      &quot;recipe&quot;: &quot;declared-dangerous-stream&quot;,
      &quot;declared_required_tools&quot;: [&quot;execute_command&quot;],
      &quot;allow_dangerous_tools&quot;: false
    }
  ],
  &quot;workflow_approve_tools&quot;: [&quot;execute_command&quot;],
  &quot;runner_tool_names&quot;: [&quot;execute_command&quot;],
  &quot;command_stdout&quot;: &quot;PRAI-CAND-012-CANARY&quot;,
  &quot;operator_env_auto_approve&quot;: 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:

Run _check_tool_policy(recipe_config) in run_stream() unless options["allow_dangerous_tools"] is true.
Perform that check before both dry-run and real execution, matching recipe.run().
Prefer a shared helper for dependency checks, dangerous-tool policy checks, and dry-run handling so future entrypoints cannot drift.
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.

Published: Jun 18, 2026
Updated: Jul 21, 2026
CVE: CVE-2026-56838
GHSA: GHSA-v847-hxxw-3pxg
Severity: High
Exploit:
CISA KEV:

CVSS v3:

Severity: High
Score: 7.8
AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWEs:

OWASP TOP 10:

A1 - Injection

Affected Software
References

Software	From	Fixed in
praisonai	4.5.87	4.6.59

https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-v847-hxxw-3pxg

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.