GHSA-w6h2-fr4q-xvxv

# Compute-bridged file tools allow shell command injection ## Summary `LocalManagedAgent` / `SandboxedAgent` compute bridging wraps `read_file`, `list_files`, and `write_file` when a compute provider is attached. The bridge converts those file operations into shell command strings using raw path arguments, then sends those strings to shell-backed compute providers. An attacker who can influence a file-tool path argument can break out of the quoted path and execute arbitrary shell commands in the compute environment. With `compute="local"`, commands execute through the local subprocess compute provider on the host. With Docker, commands execute in the container. ## Affected Product - Repository: `MervinPraison/PraisonAI` - Package: `praisonai` - Component: `src/praisonai/praisonai/integrations/managed_local.py` - Confirmed affected: - `v4.6.10` - `v4.6.56` - `v4.6.57` - current `main` at `2f9677abb2ea68eab864ee8b6a828fd0141612e1` - Confirmed not affected: - `v4.6.9` - `v4.6.1` - `v4.5.149` - Suggested affected range: `>= 4.6.10, <= 4.6.57` ## Root Cause Current `managed_local.py` defines the bridged tool set: ```python compute_bridged_tools = {"execute_command", "read_file", "write_file", "list_files"} ``` For file tools, `_bridge_file_tool()` constructs shell command strings: ```python command = f'cat "{filepath}"' command = f'ls -la "{directory}"' command = f'cat > "{filepath}" << "EOF"\n{content}\nEOF' ``` The local compute provider executes the string with `asyncio.create_subprocess_shell(...)`; the Docker compute provider executes it with `["sh", "-c", command]`. The bridge keeps the low-risk `read_file` / `list_files` tool names and signatures while changing their execution primitive into shell interpretation. ## Why This Is Not Intended Behavior Compute bridging itself is documented and intentional. The vulnerability is that file path data is interpreted as shell syntax. The normal `read_file` and `list_files` implementations treat