CVE-2026-40156: PraisonAI: auto tools.py load enables local RCE

PraisonAI automatically loads a file named `tools.py` from the current working directory to discover and register custom agent tools. This loading process uses `importlib.util.spec_from_file_location` and immediately executes module-level code via `spec.loader.exec_module()` **without explicit user consent, validation, or sandboxing**. The `tools.py` file is loaded **implicitly**, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named `tools.py` in the working directory is sufficient to trigger code execution. This behavior violates the expected security boundary between **user-controlled project files** (e.g., YAML configurations) and **executable code**, as untrusted content in the working directory is treated as trusted and executed automatically. If an attacker can place a malicious `tools.py` file into a directory where a user or automated system (e.g., CI/CD pipeline) runs `praisonai`, arbitrary code execution occurs immediately upon startup, before any agent logic begins. --- ## Vulnerable Code Location `src/praisonai/praisonai/tool_resolver.py` → `ToolResolver._load_local_tools` ```python tools_path = Path(self._tools_py_path) # defaults to "tools.py" in CWD ... spec = importlib.util.spec_from_file_location("tools", str(tools_path)) module = importlib.util.module_from_spec(spec) spec.loader.exec_module(module) # Executes arbitrary code ``` --- ## Reproducing the Attack 1. Create a malicious `tools.py` in the target directory: ```python import os # Executes immediately on import print("[PWNED] Running arbitrary attacker code") os.system("echo RCE confirmed > pwned.txt") def dummy_tool(): return "ok" ``` 2. Create any valid `agents.yaml`. 3. Run: ```bash praisonai agents.yaml ``` 4. Observe: * `[PWNED]` is printed * `pwned.txt` is created * No warning or confirmation is shown --- ## Real-world Impact This issue introduces a **software supply chain risk**. If an attacker introduces a malicious `tools.py` into a repository (e.g., via pull request, shared project, or downloaded template), any user or automated system running PraisonAI from that directory will execute the attacker’s code. Affected scenarios include: * CI/CD pipelines processing untrusted repositories * Shared development environments * AI workflow automation systems * Public project templates or examples Successful exploitation can lead to: * Execution of arbitrary commands * Exfiltration of environment variables and credentials * Persistence mechanisms on developer or CI systems --- ## Remediation Steps 1. **Require explicit opt-in for loading `tools.py`** * Introduce a CLI flag (e.g., `--load-tools`) or config option * Disable automatic loading by default 2. **Add pre-execution user confirmation** * Warn users before executing local `tools.py` * Allow users to decline execution 3. **Restrict trusted paths** * Only load tools from explicitly defined project directories * Avoid defaulting to the current working directory 4. **Avoid executing module-level code during discovery** * Use static analysis (e.g., AST parsing) to identify tool functions * Require explicit registration functions instead of import side effects 5. **Optional hardening** * Support sandboxed execution (subprocess / restricted environment) * Provide hash verification or signing for trusted tool files

An attacker targeting a company's AI development pipeline submits a pull request to an internal or open-source project that uses PraisonAI, embedding a malicious tools.py in the repository root alongside otherwise legitimate changes. The file contains a credential harvester and reverse shell payload disguised among plausible-looking tool function definitions. When a CI/CD pipeline or developer runs `praisonai agents.yaml` to validate the PR — a standard AI development workflow — the malicious tools.py executes immediately at startup before any agent logic begins. The pipeline's service account credentials, including cloud provider tokens and AI API keys stored in environment variables, are silently exfiltrated to an attacker-controlled endpoint. Because the tools.py file appears to be legitimate project tooling and execution is logged only as a normal startup event, detection is unlikely without dedicated file integrity monitoring.