CVE-2026-60085

PraisonAI before 4.6.78 contains an unenforced security policy vulnerability in the default Subprocess Sandbox backend where blocked_commands, blocked_paths, blocked_imports, allow_subprocess, and allow_file_write restrictions are completely ignored. Attackers can execute arbitrary subprocess commands, read sensitive files, and perform destructive operations despite explicit security policy configuration.

PraisonAI before 4.6.78 contains an unenforced security policy vulnerability in the default Subprocess Sandbox backend where blocked_commands, blocked_paths, blocked_imports, allow_subprocess, and allow_file_write restrictions are completely ignored. Attackers can execute arbitrary subprocess commands, read sensitive files, and perform destructive operations despite explicit security policy configuration.

Summary SecurityPolicy in praisonaiagents/sandbox/config.py is a documented configuration data class with fields for allow_subprocess, allowed_paths, blocked_paths, allowed_commands, blocked_commands, allowed_imports, and blocked_imports. Its strict() classmethod is explicitly described as creating "a strict security policy for untrusted code," setting allow_subprocess=False and allow_file_write=False, and inheriting default blocked_paths (/etc/passwd, /etc/shadow, ~/.ssh, ~/.aws, ~/.config) and blocked_commands (rm -rf, dd, mkfs, fdisk, shutdown, reboot). The default sandbox backend, Subprocess Sandbox (praisonai/sandbox/subprocess.py), implements code/command execution by writing input to a temp file and invoking it via asyncio.create_subprocess_exec() directly, with no checking of any kind against blocked_commands, blocked_imports, blocked_paths, allow_subprocess, or allow_file_write. A search across every sandbox backend file in the repository confirms these fields are referenced nowhere outside the data class that declares them. Only allow_network and max_output_size are actually consulted. Verification Using a Security Policy.strict()-configured Sandbox Config(sandbox_type="subprocess") and the real Subprocess Sandbox:

subprocess.run(['id'], ...) executed and returned uid=0(root) gid=0(root) groups=0(root) — despite allow_subprocess=False. open('/etc/passwd').read() returned the real file contents in full — despite /etc/passwd being explicitly listed in blocked_paths. A shell command containing rm -rf actually created and then deleted a real test directory (confirmed via echo DELETED after the operation) — despite "rm -rf" being explicitly listed in blocked_commands.

All three were run against the same sandbox instance in one session, confirming simultaneous failure across the policy's command, path, and subprocess restrictions. Impact Any deployment relying on the default subprocess sandbox type — including via the API's own recommended strict() configuration for untrusted code — receives no actual protection against subprocess creation, sensitive file access, or destructive command execution. Since subprocess requires no extra dependencies and is the default Sandbox Config.sandbox_type, this is plausibly the active backend in many real deployments rather than an edge case. Root cause Security Policy was designed as a backend-agnostic configuration surface, but only allow_network and max_output_size were ever wired into Subprocess Sandbox. The remaining fields exist as fully-documented configuration with no corresponding enforcement code in this backend. Suggested remediation Enforce blocked_commands/blocked_imports/blocked_paths/allow_subprocess/allow_file_write in Subprocess Sandbox before invoking the child process, or — given the well-known limits of denylist-style matching — default to the already-implemented native backend (Landlock/Seatbelt) for untrusted code rather than the unenforced subprocess backend. Consider having SecurityPolicy.strict() raise if instantiated against a backend that cannot enforce its fields.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-5r6c-gj4g-r697. This link is maintained to preserve external references.

Original Description

PraisonAI before 4.6.78 contains an unenforced security policy vulnerability in the default Subprocess Sandbox backend where blocked_commands, blocked_paths, blocked_imports, allow_subprocess, and allow_file_write restrictions are completely ignored. Attackers can execute arbitrary subprocess commands, read sensitive files, and perform destructive operations despite explicit security policy configuration.

PraisonAI before 4.6.78 contains an unenforced security policy vulnerability in the default Subprocess Sandbox backend where blocked_commands, blocked_paths, blocked_imports, allow_subprocess, and allow_file_write restrictions are completely ignored. Attackers can execute arbitrary subprocess commands, read sensitive files, and perform destructive operations despite explicit security policy configuration.

PraisonAI before 4.6.78 contains an unenforced security policy vulnerability in the default Subprocess Sandbox backend where blocked_commands, blocked_paths, blocked_imports, allow_subprocess, and allow_file_write restrictions are completely ignored. Attackers can execute arbitrary subprocess commands, read sensitive files, and perform destructive operations despite explicit security policy configuration.

Summary SecurityPolicy in praisonaiagents/sandbox/config.py is a documented configuration data class with fields for allow_subprocess, allowed_paths, blocked_paths, allowed_commands, blocked_commands, allowed_imports, and blocked_imports. Its strict() classmethod is explicitly described as creating "a strict security policy for untrusted code," setting allow_subprocess=False and allow_file_write=False, and inheriting default blocked_paths (/etc/passwd, /etc/shadow, ~/.ssh, ~/.aws, ~/.config) and blocked_commands (rm -rf, dd, mkfs, fdisk, shutdown, reboot). The default sandbox backend, Subprocess Sandbox (praisonai/sandbox/subprocess.py), implements code/command execution by writing input to a temp file and invoking it via asyncio.create_subprocess_exec() directly, with no checking of any kind against blocked_commands, blocked_imports, blocked_paths, allow_subprocess, or allow_file_write. A search across every sandbox backend file in the repository confirms these fields are referenced nowhere outside the data class that declares them. Only allow_network and max_output_size are actually consulted. Verification Using a Security Policy.strict()-configured Sandbox Config(sandbox_type="subprocess") and the real Subprocess Sandbox:

subprocess.run(['id'], ...) executed and returned uid=0(root) gid=0(root) groups=0(root) — despite allow_subprocess=False. open('/etc/passwd').read() returned the real file contents in full — despite /etc/passwd being explicitly listed in blocked_paths. A shell command containing rm -rf actually created and then deleted a real test directory (confirmed via echo DELETED after the operation) — despite "rm -rf" being explicitly listed in blocked_commands.

All three were run against the same sandbox instance in one session, confirming simultaneous failure across the policy's command, path, and subprocess restrictions. Impact Any deployment relying on the default subprocess sandbox type — including via the API's own recommended strict() configuration for untrusted code — receives no actual protection against subprocess creation, sensitive file access, or destructive command execution. Since subprocess requires no extra dependencies and is the default Sandbox Config.sandbox_type, this is plausibly the active backend in many real deployments rather than an edge case. Root cause Security Policy was designed as a backend-agnostic configuration surface, but only allow_network and max_output_size were ever wired into Subprocess Sandbox. The remaining fields exist as fully-documented configuration with no corresponding enforcement code in this backend. Suggested remediation Enforce blocked_commands/blocked_imports/blocked_paths/allow_subprocess/allow_file_write in Subprocess Sandbox before invoking the child process, or — given the well-known limits of denylist-style matching — default to the already-implemented native backend (Landlock/Seatbelt) for untrusted code rather than the unenforced subprocess backend. Consider having SecurityPolicy.strict() raise if instantiated against a backend that cannot enforce its fields.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-5r6c-gj4g-r697. This link is maintained to preserve external references.

Original Description

PraisonAI before 4.6.78 contains an unenforced security policy vulnerability in the default Subprocess Sandbox backend where blocked_commands, blocked_paths, blocked_imports, allow_subprocess, and allow_file_write restrictions are completely ignored. Attackers can execute arbitrary subprocess commands, read sensitive files, and perform destructive operations despite explicit security policy configuration.

Summary SecurityPolicy in praisonaiagents/sandbox/config.py is a documented configuration data class with fields for allow_subprocess, allowed_paths, blocked_paths, allowed_commands, blocked_commands, allowed_imports, and blocked_imports. Its strict() classmethod is explicitly described as creating "a strict security policy for untrusted code," setting allow_subprocess=False and allow_file_write=False, and inheriting default blocked_paths (/etc/passwd, /etc/shadow, ~/.ssh, ~/.aws, ~/.config) and blocked_commands (rm -rf, dd, mkfs, fdisk, shutdown, reboot). The default sandbox backend, Subprocess Sandbox (praisonai/sandbox/subprocess.py), implements code/command execution by writing input to a temp file and invoking it via asyncio.create_subprocess_exec() directly, with no checking of any kind against blocked_commands, blocked_imports, blocked_paths, allow_subprocess, or allow_file_write. A search across every sandbox backend file in the repository confirms these fields are referenced nowhere outside the data class that declares them. Only allow_network and max_output_size are actually consulted. Verification Using a Security Policy.strict()-configured Sandbox Config(sandbox_type="subprocess") and the real Subprocess Sandbox:

subprocess.run(['id'], ...) executed and returned uid=0(root) gid=0(root) groups=0(root) — despite allow_subprocess=False. open('/etc/passwd').read() returned the real file contents in full — despite /etc/passwd being explicitly listed in blocked_paths. A shell command containing rm -rf actually created and then deleted a real test directory (confirmed via echo DELETED after the operation) — despite "rm -rf" being explicitly listed in blocked_commands.

All three were run against the same sandbox instance in one session, confirming simultaneous failure across the policy's command, path, and subprocess restrictions. Impact Any deployment relying on the default subprocess sandbox type — including via the API's own recommended strict() configuration for untrusted code — receives no actual protection against subprocess creation, sensitive file access, or destructive command execution. Since subprocess requires no extra dependencies and is the default Sandbox Config.sandbox_type, this is plausibly the active backend in many real deployments rather than an edge case. Root cause Security Policy was designed as a backend-agnostic configuration surface, but only allow_network and max_output_size were ever wired into Subprocess Sandbox. The remaining fields exist as fully-documented configuration with no corresponding enforcement code in this backend. Suggested remediation Enforce blocked_commands/blocked_imports/blocked_paths/allow_subprocess/allow_file_write in Subprocess Sandbox before invoking the child process, or — given the well-known limits of denylist-style matching — default to the already-implemented native backend (Landlock/Seatbelt) for untrusted code rather than the unenforced subprocess backend. Consider having SecurityPolicy.strict() raise if instantiated against a backend that cannot enforce its fields.