Summary
PraisonAI's multi-agent system contains a code injection flaw where YAML-sourced module paths are executed via spec.loader.exec_module without adequate guarding.
An attacker who can influence the YAML configuration may load arbitrary Python modules, resulting in high-impact remote code execution on the host running PraisonAI.
PraisonAI's multi-agent system contains a code injection flaw where YAML-sourced module paths are executed via spec.loader.exec_module without adequate guarding.
An attacker who can influence the YAML configuration may load arbitrary Python modules, resulting in high-impact remote code execution on the host running PraisonAI.
Affected context
The vulnerability occurs in PraisonAI deployments that dynamically load agent modules based on YAML configuration.
Specifically, agents_generator.py uses spec.loader.exec_module on a module_path value taken directly from configuration files.
When operators allow external or user-modifiable YAML configs, and rely on automatic module loading for agents, these call sites can become an implicit execution sink for attacker-controlled code.
The vulnerability occurs in PraisonAI deployments that dynamically load agent modules based on YAML configuration.
Specifically, agents_generator.py uses spec.loader.exec_module on a module_path value taken directly from configuration files.
When operators allow external or user-modifiable YAML configs, and rely on automatic module loading for agents, these call sites can become an implicit execution sink for attacker-controlled code.
Exploit preconditions
- Attack surface: Configuration-driven module loading logic in PraisonAI.
- Required access: Ability to create or modify YAML configurations that define
module_pathfor agents (e.g., local filesystem write, CI/CD artifact control, or upstream config injection). - Trigger point: PraisonAI starts or refreshes agents, causing
agents_generator.pyto resolve the suppliedmodule_pathand callspec.loader.exec_moduleon it. - Why exploitation is possible: The
module_pathvalues are treated as trusted and executed without validation, signing, or enforcement of thePRAISONAI_ALLOW_LOCAL_TOOLSgate, so arbitrary modules can be imported and run in-process.
- Attack surface: Configuration-driven module loading logic in PraisonAI.
- Required access: Ability to create or modify YAML configurations that define
module_pathfor agents (e.g., local filesystem write, CI/CD artifact control, or upstream config injection). - Trigger point: PraisonAI starts or refreshes agents, causing
agents_generator.pyto resolve the suppliedmodule_pathand callspec.loader.exec_moduleon it. - Why exploitation is possible: The
module_pathvalues are treated as trusted and executed without validation, signing, or enforcement of thePRAISONAI_ALLOW_LOCAL_TOOLSgate, so arbitrary modules can be imported and run in-process.
Why this happens
This issue stems from dynamically loading and executing code based on untrusted configuration input, an instance of CWE-94: Improper Control of Generation of Code.
The design couples YAML configuration directly to Python module execution using spec.loader.exec_module, with no integrity checks, whitelisting, or gating mechanism.
Because configuration is treated as authoritative and not strictly bound to a constrained module registry, attackers can point PraisonAI at arbitrary code artifacts, effectively turning configuration parsing into an execution primitive.
The missed guarding around these loader call sites, compared to the tool_override.py sinks, leaves a gap where code loading is not subject to the same safety controls, creating an inconsistent and exploitable trust boundary.
This issue stems from dynamically loading and executing code based on untrusted configuration input, an instance of CWE-94: Improper Control of Generation of Code.
The design couples YAML configuration directly to Python module execution using spec.loader.exec_module, with no integrity checks, whitelisting, or gating mechanism.
Because configuration is treated as authoritative and not strictly bound to a constrained module registry, attackers can point PraisonAI at arbitrary code artifacts, effectively turning configuration parsing into an execution primitive.
The missed guarding around these loader call sites, compared to the tool_override.py sinks, leaves a gap where code loading is not subject to the same safety controls, creating an inconsistent and exploitable trust boundary.
Potential impact
- Attackers could execute arbitrary Python code in the PraisonAI process.
- Malicious agents may exfiltrate sensitive data handled by PraisonAI teams.
- Compromise of the host environment through OS-level operations from injected modules.
- Persistence mechanisms can be installed via malicious modules or backdoor agents.
- Subversion of multi-agent workflows, including data poisoning and tampering with automated decisions.
- Attackers could execute arbitrary Python code in the PraisonAI process.
- Malicious agents may exfiltrate sensitive data handled by PraisonAI teams.
- Compromise of the host environment through OS-level operations from injected modules.
- Persistence mechanisms can be installed via malicious modules or backdoor agents.
- Subversion of multi-agent workflows, including data poisoning and tampering with automated decisions.
General mitigation guidance
A robust mitigation strategy aims to decouple configuration from direct code execution and to enforce strict trust boundaries around dynamically loaded modules.
Common patterns include:
- Restricting dynamic loading to a curated, hard-coded registry of allowed module identifiers instead of arbitrary paths.
- Applying signature verification or origin checks for any module referenced from configuration, rejecting untrusted artifacts.
- Introducing configuration schema validation that constrains
module_pathto safe, pre-approved values and formats. - Enforcing runtime gates (such as environment flags or policy toggles) consistently across all execution sinks, not just tool overrides.
- Running PraisonAI with least privilege (e.g., limited filesystem, network, and OS capabilities) so that, even if a module is misloaded, its impact is reduced.
- Treating YAML and other configuration files as untrusted input whenever they can be influenced by external parties or automation pipelines, and designing loading logic accordingly.
A robust mitigation strategy aims to decouple configuration from direct code execution and to enforce strict trust boundaries around dynamically loaded modules.
Common patterns include:
- Restricting dynamic loading to a curated, hard-coded registry of allowed module identifiers instead of arbitrary paths.
- Applying signature verification or origin checks for any module referenced from configuration, rejecting untrusted artifacts.
- Introducing configuration schema validation that constrains
module_pathto safe, pre-approved values and formats. - Enforcing runtime gates (such as environment flags or policy toggles) consistently across all execution sinks, not just tool overrides.
- Running PraisonAI with least privilege (e.g., limited filesystem, network, and OS capabilities) so that, even if a module is misloaded, its impact is reduced.
- Treating YAML and other configuration files as untrusted input whenever they can be influenced by external parties or automation pipelines, and designing loading logic accordingly.
How teams detect issues like this
Effective detection focuses on identifying unsafe dynamic execution patterns and monitoring configuration-driven behavior:
- Static analysis rules that flag uses of
spec.loader.exec_module,importlibloaders, or other dynamic import APIs when arguments originate from configuration or external input. - Code review checklists that require reviewers to trace configuration parameters through to execution sinks, ensuring any new loaders are gated, validated, or constrained.
- Policy-based enforcement that mandates module registries, signatures, or environment gates for all dynamic tool and agent loading.
- Runtime logging of module loading events, including the resolved
module_pathand configuration source, with anomaly detection for unexpected modules or locations. - Optional use of automated security review tools integrated into CI/CD pipelines to scan for CWE-94 patterns and unsafe configuration parsing across PraisonAI codebases.
Effective detection focuses on identifying unsafe dynamic execution patterns and monitoring configuration-driven behavior:
- Static analysis rules that flag uses of
spec.loader.exec_module,importlibloaders, or other dynamic import APIs when arguments originate from configuration or external input. - Code review checklists that require reviewers to trace configuration parameters through to execution sinks, ensuring any new loaders are gated, validated, or constrained.
- Policy-based enforcement that mandates module registries, signatures, or environment gates for all dynamic tool and agent loading.
- Runtime logging of module loading events, including the resolved
module_pathand configuration source, with anomaly detection for unexpected modules or locations. - Optional use of automated security review tools integrated into CI/CD pipelines to scan for CWE-94 patterns and unsafe configuration parsing across PraisonAI codebases.
