SecurityPolicy command/path/import restrictions are completely unenforced by the default SubprocessSandbox backend · Advisory · MervinPraison/PraisonAI · GitHub
//repos/advisories/show" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
//repos/advisories/show;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
MervinPraison
PraisonAI
Public
Uh oh!
There was an error while loading. Please reload this page.
Notifications<br>You must be signed in to change notification settings
Fork<br>1.3k
Star<br>8.5k
SecurityPolicy command/path/import restrictions are completely unenforced by the default SubprocessSandbox backend
Critical
MervinPraison<br>published<br>GHSA-5r6c-gj4g-r697<br>Jun 25, 2026
Package
pip
praisonai<br>(pip)
Affected versions
Patched versions
>= 4.6.78
Description
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.
Severity
Critical
CVE ID
CVE-2026-62177
Weaknesses
No CWEs
Credits
LHMisme420
Reporter
You can’t perform that action at this time.