PraisonAI — CraftedSignal Threat Feed

PraisonAI Unsafe Tool Resolution Vulnerability

hello@craftedsignal.io — Mon, 11 May 2026 14:01:58 +0000

PraisonAI’s praisonaiagents library exhibits an unsafe tool resolution vulnerability. Specifically, when resolving tool names, the system searches module globals and the __main__ scope after failing to find a match in the declared tool list or the tool registry. Crucially, the default agent configuration sets _perm_allow to None, meaning that the permission gate does not enforce a strict allowlist of declared tools. This allows an attacker who can control or influence the tool-call names to invoke unintended application callables, bypassing the intended security boundary of declared tools. The vulnerability was verified on commit d8a8a786915dc67a7c3021e24f72458f2eac5d9c (v4.6.35).

Attack Chain

The attacker identifies an application callable that is accessible via __main__ or globals.
The attacker crafts a malicious input to the PraisonAI agent that specifies the name of the target callable as the “tool” to execute.
The ToolExecutionMixin.execute_tool function is called with the attacker-controlled tool name.
The agent first searches for the tool in its declared self.tools list. This search fails because the tool is undeclared.
The agent then attempts to retrieve the tool from the tool registry. This also fails.
The agent falls back to searching for the tool name in globals() and __main__. The attacker-specified callable is found in __main__.
The agent executes the callable directly, passing arguments as needed.
The attacker achieves arbitrary code execution within the context of the PraisonAI application, potentially leading to unauthorized state changes, data exposure, or command execution.

Impact

Successful exploitation of this vulnerability can have significant consequences. In deployments where untrusted parties can influence tool-call names, attackers can execute undeclared application callables, bypassing intended security boundaries. Operators who rely on the declared tool list as a security control are vulnerable, as this control can be circumvented. If the application keeps privileged helper functions in process scope, the attacker can reuse those helpers with the application’s own privileges, potentially leading to unauthorized state changes, data exposure, or command execution. Affected packages include pip/praisonaiagents (vulnerable: <= 1.6.36) and pip/PraisonAI (vulnerable: <= 4.6.36).

Recommendation

Upgrade to a patched version of praisonaiagents and PraisonAI that addresses the unsafe tool resolution (CVE-2026-44339).
Configure the PraisonAI agent to use an explicit allowlist (_perm_allow) of permitted tools to prevent the execution of undeclared callables. Refer to the PraisonAI documentation for instructions on setting up the _perm_allow parameter.
Implement input validation and sanitization on tool-call names to prevent attackers from injecting arbitrary callable names.
Deploy the Sigma rule to detect attempts to execute undeclared functions through ToolExecutionMixin.

PraisonAI Symlink Extraction Bypass Vulnerability

hello@craftedsignal.io — Mon, 11 May 2026 14:01:45 +0000

PraisonAI versions 2.7.2 through 4.6.35 are susceptible to a symlink extraction bypass vulnerability. The vulnerability exists within the _safe_extractall helper function, which is used by recipe pull, recipe publish, and recipe unpack functionalities. The core issue lies in the lack of validation for member.linkname and the failure to reject symlink members during archive extraction. This allows a malicious actor to craft a .praison bundle containing a symlink that points outside the intended destination directory, leading to arbitrary file writes. This vulnerability re-opens attack vectors that previous patches (GHSA-99g3-w8gr-x37c, GHSA-4rx4-4r3x-6534, GHSA-r9x3-wx45-2v7f, and GHSA-4ph2-f6pf-79wv) aimed to mitigate.

Attack Chain

An attacker crafts a malicious .praison bundle containing a symlink member.
The symlink’s name is within the intended destination directory.
The symlink’s linkname points to a location outside the destination directory (e.g., /tmp/PWNED).
The malicious bundle also includes a regular file member.
The regular file’s path traverses through the previously created symlink (e.g., legit/escape/owned.txt).
A user or server processes the malicious .praison bundle using praisonai recipe unpack, praisonai recipe pull, or a registry archive validation process.
During extraction, the symlink is created first, pointing to the attacker-controlled location.
When the regular file is extracted, it follows the symlink, resulting in an arbitrary file write to the attacker’s chosen location.

Impact

Successful exploitation allows an attacker to write arbitrary files with attacker-controlled content to any location on the filesystem accessible to the PraisonAI process. This can lead to various outcomes, including: overwriting user configuration files (.bashrc, .zshrc, .profile, SSH authorized_keys, cron entries), modifying project files, or, if the process runs as root, compromising the entire system. This vulnerability impacts all hosts processing malicious .praison bundles through affected praisonai versions.

Recommendation

Upgrade to a patched version of PraisonAI that includes the filter="data" argument in the tar.extractall call to prevent symlink extraction bypass (recipe/registry.py:178).
For older Python versions, implement an explicit check for symlinks and hardlinks during archive extraction, validating that the link target remains within the intended destination directory as described in the suggested remediation.
Deploy the Sigma rule “Detect PraisonAI Symlink Extraction Bypass” to identify potential exploitation attempts by monitoring for archive extractions containing suspicious symlinks.

PraisonAI MCP Path Traversal to RCE via .pth Injection

hello@craftedsignal.io — Mon, 11 May 2026 13:59:36 +0000

PraisonAI’s MCP (Model Context Protocol) server registers four file-handling tools by default: praisonai.rules.create, praisonai.rules.show, praisonai.rules.delete, and praisonai.workflow.show. Each accepts a path or filename string from MCP tools/call arguments and joins it onto ~/.praison/rules/ (or accepts an absolute path for workflow.show) without proper validation. The JSON-RPC dispatcher passes params["arguments"] without validating against the advertised input schema. This allows an attacker to write arbitrary files by escaping the rules directory, leading to arbitrary code execution via Python .pth injection into the user site-packages directory. The vulnerability can be exploited via LLMs with poisoned context, unauthenticated HTTP-stream transports, or prompt injection. No operator misconfiguration is required to trigger the vulnerability.

Attack Chain

An attacker poisons the context of an LLM connected to a PraisonAI MCP server through attacker-controlled web content, documents, or emails.
The user interacts with the LLM, asking it to summarize or analyze the poisoned content, which contains a crafted command.
The LLM, under prompt injection, crafts a tools/call request to the MCP server, targeting praisonai.rules.create with a malicious rule_name.
The crafted rule_name includes path traversal sequences (e.g., ../../) to write a file outside the intended rules directory.
The MCP server’s rules.create handler, lacking containment checks, writes the file to a location such as the user’s site-packages directory (e.g., ~/.local/lib/python3.14/site-packages/evil.pth).
The written file is a Python .pth file containing an import os; os.system("malicious_command") statement.
The next time the user starts a Python interpreter (including the praisonai CLI), the .pth file is processed, executing the attacker’s arbitrary code.
The attacker achieves arbitrary code execution with the user’s privileges, potentially leading to data exfiltration, system compromise, or lateral movement.

Impact

Successful exploitation allows an attacker to achieve arbitrary code execution on the victim’s machine. This can lead to data exfiltration, installation of malware, or further compromise of the system. The vulnerability affects any user running a PraisonAI MCP server connected to an LLM without proper input validation, and the default configuration of the HTTP-stream transport exposes the server to local attacks without requiring authentication. The impact is significant as it can compromise the user’s entire system and any data accessible to the user account.

Recommendation

Apply input validation and containment to all file-handling tools. Specifically, implement checks to prevent path traversal in praisonai.rules.create, praisonai.rules.show, and praisonai.rules.delete as detailed in the “Suggested fix” section of the advisory.
Enforce schema validation in the MCP dispatcher to ensure that params["arguments"] conforms to the expected schema, rejecting unknown properties and type mismatches.
Restrict the workflow.show tool to only accept paths within a designated workflow directory and reject absolute paths or any value containing .., as outlined in the “Suggested fix” section.
Deploy the Sigma rules provided in this brief to detect potential exploitation attempts and tune them for your environment.
Require authentication on non-loopback HTTP-stream binds to prevent unauthorized access to the MCP server when using praisonai mcp serve --transport http-stream.

PraisonAI Legacy API Server Authentication Bypass (CVE-2026-44338)

hello@craftedsignal.io — Mon, 11 May 2026 13:57:56 +0000

PraisonAI includes a legacy Flask API server (src/praisonai/api_server.py) that, by default, ships with authentication disabled. This is due to hardcoded values AUTH_ENABLED = False and AUTH_TOKEN = None, causing the check_auth() function to always return True and effectively bypass authentication checks on /agents and /chat endpoints. The affected versions range from v2.5.6 to 4.6.33, which is the current PyPI release as of May 1, 2026. The serve agents command is not affected, but the older api_server.py binds to 0.0.0.0:8080 by default, and the generated sample API deployment YAML recommends host: 0.0.0.0 together with auth_enabled: false, further exacerbating the issue. This vulnerability, identified as CVE-2026-44338, allows unauthenticated access to sensitive functionality.

Attack Chain

Target identifies a PraisonAI instance running the vulnerable legacy API server.
Target sends a GET request to /agents endpoint to enumerate available agents.
The API server, due to disabled authentication, grants access to the /agents endpoint without requiring any authentication credentials.
The server responds with agent metadata, revealing the configured agents.yaml file.
Target crafts a POST request to the /chat endpoint, including a message key in the JSON payload.
The API server processes the request, bypassing authentication, and executes the workflow defined in agents.yaml by calling PraisonAI(agent_file="agents.yaml").run().
The API server returns the result of the PraisonAI.run() call to the unauthenticated attacker.
Depending on the configuration specified in agents.yaml, this can result in data exfiltration, code execution, or denial of service via resource exhaustion.

Impact

Successful exploitation allows any attacker with network access to the vulnerable PraisonAI instance to enumerate configured agents, trigger workflows defined in agents.yaml, consume model/API quota, and potentially expose sensitive information. The impact is determined by the capabilities defined in the agents.yaml file, but the authentication bypass itself is unconditional in the shipped legacy server. This vulnerability affects PraisonAI versions 2.5.6 through 4.6.33.

Recommendation

Deploy the Sigma rule “Detect Unauthenticated Access to PraisonAI Agents Endpoint” to detect unauthenticated access attempts to the /agents endpoint within your web server logs.
Deploy the Sigma rule “Detect Unauthenticated Chat Request to PraisonAI API Server” to identify unauthorized requests being made to the /chat endpoint to trigger workflow executions.
Upgrade PraisonAI to a version that addresses CVE-2026-44338 or migrate to the newer serve agents command which defaults to binding on localhost and supports API keys.
If upgrading is not immediately feasible, ensure the legacy API server’s AUTH_ENABLED setting is set to True and configure a strong AUTH_TOKEN to mitigate the unauthenticated access vulnerability.
Review and restrict network access to the legacy API server to minimize the attack surface and prevent unauthorized external access to the vulnerable endpoints.