PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, is_path_within_directory() uses os.path.abspath() rather than os.path.realpath() for the workspace boundary. A symlink inside workspace can point outside and still pass the check, allowing read_file and other code tools to access files outside the configured workspace. This issue is fixed in version 4.6.58.

Affected: PyPI: PraisonAI

### Summary PraisonAI's `praisonai.code` tool wrappers (exported as `CODE_TOOLS` for agents) expose a `workspace` setting that the module itself treats as a path-traversal **security boundary** — `read_file`, `write_file`, `apply_diff`, and `search_replace` explicitly call `is_path_within_directory()` and return `"… is outside the workspace"` on violations. That boundary is enforced **unsoundly and inconsistently**: 1. The containment helper uses `os.path.abspath()`, not `realpath()`/`Path.resolve()`. A symlink located **inside** the workspace whose target is **outside** has an `abspath()` that is still inside the workspace, so it passes the check while `open()` follows the link. This bypasses read, write, apply_diff, and search_replace (CWE-59). 2. `list_files()` resolves `path` against the workspace but **never** calls the containment helper at all — `../` and absolute paths escape directly (CWE-22). 3. `execute_command()` takes a `workspace` argument documented "for security validation" but performs **no** `cwd` containment check; `code_execute_command()` resolves a relative `cwd` against the workspace and also never validates it (and never even passes `workspace` to the low-level helper). A relative `cwd="../outside"` runs commands from outside the workspace (CWE-22). An attacker who can influence an agent that has these tools attached (untrusted prompt, indirect prompt injection, or a server-exposed agent) can read, overwrite, list, and execute from outside the config…

Affected: PyPI: praisonai

### Summary PraisonAI's `praisonai.code` tool wrappers (exported as `CODE_TOOLS` for agents) expose a `workspace` setting that the module itself treats as a path-traversal **security boundary** — `read_file`, `write_file`, `apply_diff`, and `search_replace` explicitly call `is_path_within_directory()` and return `"… is outside the workspace"` on violations. That boundary is enforced **unsoundly and inconsistently**: 1. The containment helper uses `os.path.abspath()`, not `realpath()`/`Path.resolve()`. A symlink located **inside** the workspace whose target is **outside** has an `abspath()` that is still inside the workspace, so it passes the check while `open()` follows the link. This bypasses read, write, apply_diff, and search_replace (CWE-59). 2. `list_files()` resolves `path` against the workspace but **never** calls the containment helper at all — `../` and absolute paths escape directly (CWE-22). 3. `execute_command()` takes a `workspace` argument documented "for security validation" but performs **no** `cwd` containment check; `code_execute_command()` resolves a relative `cwd` against the workspace and also never validates it (and never even passes `workspace` to the low-level helper). A relative `cwd="../outside"` runs commands from outside the workspace (CWE-22). An attacker who can influence an agent that has these tools attached (untrusted prompt, indirect prompt injection, or a server-exposed agent) can read, overwrite, list, and execute from outside the config…