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.
praisonai2f9677abb2ea68eab864ee8b6a828fd0141612e1v4.6.57src/praisonai/praisonai/code/agent_tools.pysrc/praisonai/praisonai/code/tools/read_file.pysrc/praisonai/praisonai/code/tools/search_replace.pysrc/praisonai/praisonai/code/tools/apply_diff.pyagent_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.
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.
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:
code_search_replace or code_apply_diff;code_read_file to first learn file content and then code_apply_diff to produce an exact modification;set_workspace() first.This issue does not claim set_workspace() is ineffective. The control works when configured. The vulnerability is the fail-open default for the advertised agent-tool bundle and adjacent read/edit helpers.
The same behavior was reproduced on:
2f9677abb2ea68eab864ee8b6a828fd0141612e1v4.6.57v4.6.56v4.6.10v4.6.9v4.5.128v4.5.126v3.9.26v3.9.24Recommended fix:
effective_workspace = workspace or os.getcwd() before resolving paths.code_read_file, code_list_files, code_apply_diff, code_search_replace, and code_execute_command use os.getcwd() as the default workspace when _workspace_root is None.set_workspace().CODE_TOOLS is used before a workspace is configured, or log a warning when the default current working directory is used.PraisonAI's official security documentation lists GitHub Security Advisories as the preferred reporting method and asks reports to include reproduction steps, affected versions, impact, and suggested fixes. The repository security policy page currently shows no configured SECURITY.md, but private vulnerability reporting is available.
| Software | From | Fixed in |
|---|---|---|
praisonai
|
- | 4.6.59 |
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.