CVE-2026-57133 in PraisonAI
Summary
by MITRE • 09/15/2026
PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, the shell() helper exported from src/praisonai-ts/src/tools/utility-tools.ts checks only the first whitespace-delimited token against safeCommands and then passes the complete original string to child_process.exec(). A string that starts with an allowed read-only command can append a second non-allowlisted command through shell syntax, allowing arbitrary command execution with the PraisonAI process privileges. This issue is fixed in version 1.7.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified within PraisonAI versions ranging from 1.5.1 to 1.7.2 represents a critical insecure implementation of shell command validation, specifically classified under CWE-78 Improper Neutralization of Special Elements used in an OS Command, commonly known as OS Command Injection. The root cause lies in the flawed logic within the shell helper function located at src/praisonai-ts/src/tools/utility-tools.ts. This utility is designed to execute system commands through Node.js child processes but fails to adequately sanitize or validate user-supplied input before execution. Instead of performing a comprehensive analysis of the entire command string, the implementation only inspects the first whitespace-delimited token against a predefined list of safe commands. This partial validation approach creates a significant security gap that attackers can exploit by leveraging standard shell metacharacters and syntax to bypass the whitelist restriction.
The operational mechanism of this exploitation relies on the behavior of POSIX-compliant shells, which interpret specific characters such as semicolons, ampersands, pipes, and backticks as command separators or operators rather than literal data. By crafting an input string that begins with a whitelisted read-only command followed by one of these shell metacharacters, an attacker can append arbitrary commands to the original request. For instance, if the safeCommands list includes ls, an attacker could supply the input ls; rm -rf / or cat file.txt && whoami. The validation logic accepts this string because it starts with ls, but the underlying child_process.exec() function interprets the semicolon as a command terminator and proceeds to execute both the allowed ls command and the malicious subsequent commands like rm or whoami. This results in arbitrary code execution with the privileges of the PraisonAI process, which can range from local file system manipulation to complete server compromise depending on the context in which the application runs.
From an offensive security perspective, this vulnerability aligns closely with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, specifically sub-techniques involving shell commands such as sh or bash. The attack vector allows for remote code execution if the vulnerable function is exposed to untrusted input via a network service or API endpoint. The impact of this flaw extends beyond simple command injection; it enables privilege escalation within the application context, data exfiltration through unauthorized file reads, and potential lateral movement within the host environment if the PraisonAI process operates with elevated permissions. In multi-agent systems like PraisonAI, where automated agents may execute various tasks based on user prompts or internal logic, this vulnerability could be triggered indirectly by malicious agent behaviors or crafted inputs designed to trick the system into executing harmful shell operations.
The resolution for this issue was implemented in version 1.7.2 of PraisonAI, which corrects the validation logic to ensure that the entire command string is properly sanitized and validated against safe patterns rather than just the initial token. To mitigate similar risks in other systems or while awaiting updates, developers should avoid using child_process.exec() with user-supplied input whenever possible. Instead, they should utilize functions like execFile(), which do not invoke a shell by default and thus prevent the interpretation of shell metacharacters as command operators. If shell execution is strictly necessary, inputs must be rigorously validated using allowlists that check for exact matches or use robust regular expressions that reject any presence of special characters such as semicolons, pipes, ampersands, backticks, dollar signs, and parentheses. Additionally, implementing principle of least privilege by running the application with minimal required system permissions can significantly reduce the potential impact of a successful exploitation attempt.