GHSA-gcq3-mfvh-3x25

# PraisonAI Code agent tools fail open without a workspace boundary ## Summary PraisonAI Code's agent-compatible `CODE_TOOLS` wrappers keep a global workspace root initialized to `None`. If an application uses `CODE_TOOLS`, `code_read_file`, `code_search_replace`, or `code_apply_diff` before calling `set_workspace()`, the wrappers pass `workspace=None` into lower-level helpers that only enforce path containment when a workspace is truthy. Absolute paths outside the intended project workspace are then read and modified. The official examples correctly call `set_workspace()` before `CODE_TOOLS`, and this report does not claim configured workspaces are ineffective. The issue is the fail-open default. PraisonAI's security documentation describes workspace boundaries as the path-traversal protection mechanism, and the already-published Python API arbitrary file write advisory (`GHSA-hvhp-v2gc-268q`) was fixed by defaulting an unset workspace to `os.getcwd()`. The adjacent read and edit paths reached through `CODE_TOOLS` still fail open. ## Affected Components - Package: `praisonai` - Current upstream main tested: `2f9677abb2ea68eab864ee8b6a828fd0141612e1` - Latest tested release: `v4.6.57` - Primary files: - `src/praisonai/praisonai/code/agent_tools.py` - `src/praisonai/praisonai/code/tools/read_file.py` - `src/praisonai/praisonai/code/tools/search_replace.py` - `src/praisonai/praisonai/code/tools/apply_diff.py` ## Root Cause `agent_tools.py` initializes `_workspace_root` to `None` and passes it directly to lower-level helpers: ```python _workspace_root: Optional[str] = None ... result = _read_file(..., workspace=_workspace_root) ... result = _search_replace(..., workspace=_workspace_root) ``` The lower-level helpers only enforce containment if `workspace` is set: ```python if workspace: if not is_path_within_directory(abs_path, workspace): return {"success": False, ...} ``` The already-hardened `write_file()` path uses `effective_workspace