CVE-2026-56839

PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODE_TOOLS wrappers keep _workspace_root as None and pass workspace=None to read_file, search_replace, and apply_diff helpers that enforce path containment only for a truthy workspace. An application that exposes code_read_file, code_search_replace, or code_apply_diff before set_workspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59.

PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODE_TOOLS wrappers keep _workspace_root as None and pass workspace=None to read_file, search_replace, and apply_diff helpers that enforce path containment only for a truthy workspace. An application that exposes code_read_file, code_search_replace, or code_apply_diff before set_workspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59.

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:

_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:

if workspace:
    if not is_path_within_directory(abs_path, workspace):
        return {"success": False, ...}

The already-hardened write_file() path uses effective_workspace = workspace or os.getcwd(). Current tests assert that write_file(workspace=None) must stay inside the current working directory. The same fail-closed default is missing from read_file, search_replace, apply_diff, and the agent wrappers that call them.

Local-Only Reproduction

Run:

PYTHONPATH=/path/to/PraisonAI/src/praisonai:/path/to/PraisonAI/src/praisonai-agents \
  python poc_code_tools_workspace_bypass.py

Expected vulnerable result:

[poc] HIT: CODE_TOOLS wrappers read and edit outside workspace when workspace is unset

The PoV creates a temporary workspace and a temporary file outside that workspace. With get_workspace() == None, code_read_file() reads the outside file, code_search_replace() modifies it, and code_apply_diff() modifies it again. After set_workspace(workspace), the same outside path is rejected by all three wrappers.

No external services, model providers, or network access are used.

Impact

If an application exposes PraisonAI Code's agent-compatible CODE_TOOLS to an LLM before setting a workspace boundary, prompt-influenced tool calls can read and modify files outside the intended project workspace. The practical attack shape matches the existing PraisonAI prompt-content advisory pattern: untrusted content influences an agent that has been given file-editing tools.

Practical impacts include:

• reading host secrets or local configuration files accessible to the process user;
• modifying arbitrary existing files when the attacker can supply or infer matching content for code_search_replace or code_apply_diff;
• using code_read_file to first learn file content and then code_apply_diff to produce an exact modification;
• bypassing the advertised workspace-boundary security posture unless the embedding application remembered to call set_workspace() first.

This issue does not claim set_workspace() is ineffective. The control works when configured. The vulnerability is the fail-open…

PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODE_TOOLS wrappers keep _workspace_root as None and pass workspace=None to read_file, search_replace, and apply_diff helpers that enforce path containment only for a truthy workspace. An application that exposes code_read_file, code_search_replace, or code_apply_diff before set_workspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59.

PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODE_TOOLS wrappers keep _workspace_root as None and pass workspace=None to read_file, search_replace, and apply_diff helpers that enforce path containment only for a truthy workspace. An application that exposes code_read_file, code_search_replace, or code_apply_diff before set_workspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59.

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:

_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:

if workspace:
    if not is_path_within_directory(abs_path, workspace):
        return {"success": False, ...}

The already-hardened write_file() path uses effective_workspace = workspace or os.getcwd(). Current tests assert that write_file(workspace=None) must stay inside the current working directory. The same fail-closed default is missing from read_file, search_replace, apply_diff, and the agent wrappers that call them.

Local-Only Reproduction

Run:

PYTHONPATH=/path/to/PraisonAI/src/praisonai:/path/to/PraisonAI/src/praisonai-agents \
  python poc_code_tools_workspace_bypass.py

Expected vulnerable result:

[poc] HIT: CODE_TOOLS wrappers read and edit outside workspace when workspace is unset

The PoV creates a temporary workspace and a temporary file outside that workspace. With get_workspace() == None, code_read_file() reads the outside file, code_search_replace() modifies it, and code_apply_diff() modifies it again. After set_workspace(workspace), the same outside path is rejected by all three wrappers.

No external services, model providers, or network access are used.

Impact

If an application exposes PraisonAI Code's agent-compatible CODE_TOOLS to an LLM before setting a workspace boundary, prompt-influenced tool calls can read and modify files outside the intended project workspace. The practical attack shape matches the existing PraisonAI prompt-content advisory pattern: untrusted content influences an agent that has been given file-editing tools.

Practical impacts include:

• reading host secrets or local configuration files accessible to the process user;
• modifying arbitrary existing files when the attacker can supply or infer matching content for code_search_replace or code_apply_diff;
• using code_read_file to first learn file content and then code_apply_diff to produce an exact modification;
• bypassing the advertised workspace-boundary security posture unless the embedding application remembered to call set_workspace() first.

This issue does not claim set_workspace() is ineffective. The control works when configured. The vulnerability is the fail-open…

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:

_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:

if workspace:
    if not is_path_within_directory(abs_path, workspace):
        return {"success": False, ...}

The already-hardened write_file() path uses effective_workspace = workspace or os.getcwd(). Current tests assert that write_file(workspace=None) must stay inside the current working directory. The same fail-closed default is missing from read_file, search_replace, apply_diff, and the agent wrappers that call them.

Local-Only Reproduction

Run:

PYTHONPATH=/path/to/PraisonAI/src/praisonai:/path/to/PraisonAI/src/praisonai-agents \
  python poc_code_tools_workspace_bypass.py

Expected vulnerable result:

[poc] HIT: CODE_TOOLS wrappers read and edit outside workspace when workspace is unset

The PoV creates a temporary workspace and a temporary file outside that workspace. With get_workspace() == None, code_read_file() reads the outside file, code_search_replace() modifies it, and code_apply_diff() modifies it again. After set_workspace(workspace), the same outside path is rejected by all three wrappers.

No external services, model providers, or network access are used.

Impact

If an application exposes PraisonAI Code's agent-compatible CODE_TOOLS to an LLM before setting a workspace boundary, prompt-influenced tool calls can read and modify files outside the intended project workspace. The practical attack shape matches the existing PraisonAI prompt-content advisory pattern: untrusted content influences an agent that has been given file-editing tools.

Practical impacts include:

• reading host secrets or local configuration files accessible to the process user;
• modifying arbitrary existing files when the attacker can supply or infer matching content for code_search_replace or code_apply_diff;
• using code_read_file to first learn file content and then code_apply_diff to produce an exact modification;
• bypassing the advertised workspace-boundary security posture unless the embedding application remembered to call set_workspace() first.

This issue does not claim set_workspace() is ineffective. The control works when configured. The vulnerability is the fail-open…