GHSA-5r6c-gj4g-r697: Pip/praisonai vulnerability

Summary SecurityPolicy in praisonaiagents/sandbox/config.py is a documented configuration data class with fields for allowsubprocess, allowedpaths, blockedpaths, allowedcommands, blockedcommands, allowedimports, and blockedimports. Its strict() classmethod is explicitly described as creating "a strict security policy for untrusted code," setting allowsubprocess=False and allowfilewrite=False, and inheriting default blockedpaths (/etc/passwd, /etc/shadow, ~/.ssh, ~/.aws, ~/.config) and blockedcommands (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.createsubprocessexec() directly, with no checking of any kind against blockedcommands, blockedimports, blockedpaths, allowsubprocess, or allowfilewrite. A search across every sandbox backend file in the repository confirms these fields are referenced nowhere outside the data class that declares them. Only allownetwork and maxoutputsize are actually consulted. Verification Using a Security Policy.strict()-configured Sandbox Config(sandboxtype="subprocess") and the real Subprocess Sandbox:

subprocess.run(['id'], ...) executed and returned uid=0(root) gid=0(root) groups=0(root) — despite allowsubprocess=False. open('/etc/passwd').read() returned the real file contents in full — despite /etc/passwd being explicitly listed in blockedpaths. 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 blockedcommands.

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.sandboxtype, 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 allownetwork and maxoutputsize 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 blockedcommands/blockedimports/blockedpaths/allowsubprocess/allowfilewrite 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.