CVE-2026-55522

PraisonAI is a multi-agent teams system. In versions 3.9.26 through 4.6.57 of praiseonai and 0.12.12 through 1.6.57 of praiseonaiagents, the workflow "include" feature is vulnerable to code execution. Workflow._execute_include() implicitly imports and runs an included recipe's tools.py via a raw importlib.util.spec_from_file_location() and spec.loader.exec_module() call, without honoring the PRAISONAI_ALLOW_TEMPLATE_TOOLS/PRAISONAI_ALLOW_LOCAL_TOOLS autoload opt-in gates or routing through the centralized safe loader that protects the other tools.py autoload paths. As a result, a workflow that includes an attacker-controlled local recipe directory executes arbitrary module-level Python code during include setup, before any child workflow parsing or model call, and the same sink is reachable through the higher-level praisonai.recipe.run() recipe API. An attacker who can cause a victim process to run a workflow or recipe that includes an untrusted local recipe achieves arbitrary Python code execution as the PraisonAI process user, a variant that bypasses the hardening applied to the previously disclosed automatic tools.py RCE advisory family. This issue has been fixed in version 4.6.58 of praisonai and 1.6.58 of praisonaiagents.

PraisonAI is a multi-agent teams system. In versions 3.9.26 through 4.6.57 of praiseonai and 0.12.12 through 1.6.57 of praiseonaiagents, the workflow "include" feature is vulnerable to code execution. Workflow._execute_include() implicitly imports and runs an included recipe's tools.py via a raw importlib.util.spec_from_file_location() and spec.loader.exec_module() call, without honoring the PRAISONAI_ALLOW_TEMPLATE_TOOLS/PRAISONAI_ALLOW_LOCAL_TOOLS autoload opt-in gates or routing through the centralized safe loader that protects the other tools.py autoload paths. As a result, a workflow that includes an attacker-controlled local recipe directory executes arbitrary module-level Python code during include setup, before any child workflow parsing or model call, and the same sink is reachable through the higher-level praisonai.recipe.run() recipe API. An attacker who can cause a victim process to run a workflow or recipe that includes an untrusted local recipe achieves arbitrary Python code execution as the PraisonAI process user, a variant that bypasses the hardening applied to the previously disclosed automatic tools.py RCE advisory family. This issue has been fixed in version 4.6.58 of praisonai and 1.6.58 of praisonaiagents.

Summary

PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset.

This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.

The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.

This is distinct from the previously published tool_resolver.py, api/call.py, templates/tool_override.py, and agents_generator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature.

Affected Components

• Package: praisonaiagents
• File: praisonaiagents/workflows/workflows.py
• Sink: Workflow._execute_include()
• Current affected callsite:

tools_py = recipe_path / "tools.py"
if tools_py.exists():
    spec = importlib.util.spec_from_file_location("recipe_tools", tools_py)
    recipe_module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(recipe_module)

The current head also contains a similar unguarded workflow-local tools.py import in _resolve_pydantic_class(). That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.

Security Boundary

PraisonAI documents secure defaults for implicit tools.py autoload:

• PRAISONAI_ALLOW_TEMPLATE_TOOLS controls implicit template/CWD tools.py autoload and is disabled by default.
• PRAISONAI_ALLOW_LOCAL_TOOLS controls automatic loading of local tools.py files and requires the value true.
• Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in.
• Existing regression tests for GHSA-xcmw-grxf-wjhj assert that template/CWD tools.py must not execute by default.

Workflow._execute_include() does not check PRAISONAI_ALLOW_TEMPLATE_TOOLS, does not check PRAISONAI_ALLOW_LOCAL_TOOLS, and does not route through the shared safe loader before executing the included recipe's tools.py.

The report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover Include, include(), YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe's tools.py unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.

The report also is not claiming that recipe tools.py files are inherently unsafe or unsupported. Official recipe documentation describes tools.py as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit tools.py autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.

Impact

An attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.

The payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.

Reproduction

Run the attached local-only PoV:

python3 pov.py

Expected vulnerable output:

VULNERABLE: included recipe tools.py executed with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset
marker=...
marker_content=executed

The PoV:

1. Unsets PRAISONAI_ALLOW_LOCAL_TOOLS and…

PraisonAI is a multi-agent teams system. In versions 3.9.26 through 4.6.57 of praiseonai and 0.12.12 through 1.6.57 of praiseonaiagents, the workflow "include" feature is vulnerable to code execution. Workflow._execute_include() implicitly imports and runs an included recipe's tools.py via a raw importlib.util.spec_from_file_location() and spec.loader.exec_module() call, without honoring the PRAISONAI_ALLOW_TEMPLATE_TOOLS/PRAISONAI_ALLOW_LOCAL_TOOLS autoload opt-in gates or routing through the centralized safe loader that protects the other tools.py autoload paths. As a result, a workflow that includes an attacker-controlled local recipe directory executes arbitrary module-level Python code during include setup, before any child workflow parsing or model call, and the same sink is reachable through the higher-level praisonai.recipe.run() recipe API. An attacker who can cause a victim process to run a workflow or recipe that includes an untrusted local recipe achieves arbitrary Python code execution as the PraisonAI process user, a variant that bypasses the hardening applied to the previously disclosed automatic tools.py RCE advisory family. This issue has been fixed in version 4.6.58 of praisonai and 1.6.58 of praisonaiagents.

PraisonAI is a multi-agent teams system. In versions 3.9.26 through 4.6.57 of praiseonai and 0.12.12 through 1.6.57 of praiseonaiagents, the workflow "include" feature is vulnerable to code execution. Workflow._execute_include() implicitly imports and runs an included recipe's tools.py via a raw importlib.util.spec_from_file_location() and spec.loader.exec_module() call, without honoring the PRAISONAI_ALLOW_TEMPLATE_TOOLS/PRAISONAI_ALLOW_LOCAL_TOOLS autoload opt-in gates or routing through the centralized safe loader that protects the other tools.py autoload paths. As a result, a workflow that includes an attacker-controlled local recipe directory executes arbitrary module-level Python code during include setup, before any child workflow parsing or model call, and the same sink is reachable through the higher-level praisonai.recipe.run() recipe API. An attacker who can cause a victim process to run a workflow or recipe that includes an untrusted local recipe achieves arbitrary Python code execution as the PraisonAI process user, a variant that bypasses the hardening applied to the previously disclosed automatic tools.py RCE advisory family. This issue has been fixed in version 4.6.58 of praisonai and 1.6.58 of praisonaiagents.

Summary

PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset.

This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.

The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.

This is distinct from the previously published tool_resolver.py, api/call.py, templates/tool_override.py, and agents_generator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature.

Affected Components

• Package: praisonaiagents
• File: praisonaiagents/workflows/workflows.py
• Sink: Workflow._execute_include()
• Current affected callsite:

tools_py = recipe_path / "tools.py"
if tools_py.exists():
    spec = importlib.util.spec_from_file_location("recipe_tools", tools_py)
    recipe_module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(recipe_module)

The current head also contains a similar unguarded workflow-local tools.py import in _resolve_pydantic_class(). That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.

Security Boundary

PraisonAI documents secure defaults for implicit tools.py autoload:

• PRAISONAI_ALLOW_TEMPLATE_TOOLS controls implicit template/CWD tools.py autoload and is disabled by default.
• PRAISONAI_ALLOW_LOCAL_TOOLS controls automatic loading of local tools.py files and requires the value true.
• Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in.
• Existing regression tests for GHSA-xcmw-grxf-wjhj assert that template/CWD tools.py must not execute by default.

Workflow._execute_include() does not check PRAISONAI_ALLOW_TEMPLATE_TOOLS, does not check PRAISONAI_ALLOW_LOCAL_TOOLS, and does not route through the shared safe loader before executing the included recipe's tools.py.

The report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover Include, include(), YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe's tools.py unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.

The report also is not claiming that recipe tools.py files are inherently unsafe or unsupported. Official recipe documentation describes tools.py as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit tools.py autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.

Impact

An attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.

The payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.

Reproduction

Run the attached local-only PoV:

python3 pov.py

Expected vulnerable output:

VULNERABLE: included recipe tools.py executed with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset
marker=...
marker_content=executed

The PoV:

1. Unsets PRAISONAI_ALLOW_LOCAL_TOOLS and…

Summary

PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset.

This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.

The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.

This is distinct from the previously published tool_resolver.py, api/call.py, templates/tool_override.py, and agents_generator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature.

Affected Components

• Package: praisonaiagents
• File: praisonaiagents/workflows/workflows.py
• Sink: Workflow._execute_include()
• Current affected callsite:

tools_py = recipe_path / "tools.py"
if tools_py.exists():
    spec = importlib.util.spec_from_file_location("recipe_tools", tools_py)
    recipe_module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(recipe_module)

The current head also contains a similar unguarded workflow-local tools.py import in _resolve_pydantic_class(). That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.

Security Boundary

PraisonAI documents secure defaults for implicit tools.py autoload:

• PRAISONAI_ALLOW_TEMPLATE_TOOLS controls implicit template/CWD tools.py autoload and is disabled by default.
• PRAISONAI_ALLOW_LOCAL_TOOLS controls automatic loading of local tools.py files and requires the value true.
• Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in.
• Existing regression tests for GHSA-xcmw-grxf-wjhj assert that template/CWD tools.py must not execute by default.

Workflow._execute_include() does not check PRAISONAI_ALLOW_TEMPLATE_TOOLS, does not check PRAISONAI_ALLOW_LOCAL_TOOLS, and does not route through the shared safe loader before executing the included recipe's tools.py.

The report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover Include, include(), YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe's tools.py unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.

The report also is not claiming that recipe tools.py files are inherently unsafe or unsupported. Official recipe documentation describes tools.py as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit tools.py autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.

Impact

An attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.

The payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.

Reproduction

Run the attached local-only PoV:

python3 pov.py

Expected vulnerable output:

VULNERABLE: included recipe tools.py executed with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset
marker=...
marker_content=executed

The PoV:

1. Unsets PRAISONAI_ALLOW_LOCAL_TOOLS and…

Summary

PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset.

This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.

The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.

This is distinct from the previously published tool_resolver.py, api/call.py, templates/tool_override.py, and agents_generator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature.

Affected Components

• Package: praisonaiagents
• File: praisonaiagents/workflows/workflows.py
• Sink: Workflow._execute_include()
• Current affected callsite:

tools_py = recipe_path / "tools.py"
if tools_py.exists():
    spec = importlib.util.spec_from_file_location("recipe_tools", tools_py)
    recipe_module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(recipe_module)

The current head also contains a similar unguarded workflow-local tools.py import in _resolve_pydantic_class(). That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.

Security Boundary

PraisonAI documents secure defaults for implicit tools.py autoload:

• PRAISONAI_ALLOW_TEMPLATE_TOOLS controls implicit template/CWD tools.py autoload and is disabled by default.
• PRAISONAI_ALLOW_LOCAL_TOOLS controls automatic loading of local tools.py files and requires the value true.
• Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in.
• Existing regression tests for GHSA-xcmw-grxf-wjhj assert that template/CWD tools.py must not execute by default.

Workflow._execute_include() does not check PRAISONAI_ALLOW_TEMPLATE_TOOLS, does not check PRAISONAI_ALLOW_LOCAL_TOOLS, and does not route through the shared safe loader before executing the included recipe's tools.py.

The report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover Include, include(), YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe's tools.py unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.

The report also is not claiming that recipe tools.py files are inherently unsafe or unsupported. Official recipe documentation describes tools.py as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit tools.py autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.

Impact

An attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.

The payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.

Reproduction

Run the attached local-only PoV:

python3 pov.py

Expected vulnerable output:

VULNERABLE: included recipe tools.py executed with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset
marker=...
marker_content=executed

The PoV:

1. Unsets PRAISONAI_ALLOW_LOCAL_TOOLS and…