CVE-2026-56839: Praisonai PraisonAI Code Agent Tools Fail Vulnerability

HIGH
Advisory Identifier: GHSA-gcq3-mfvh-3x25
CVSS 7.3
CWE-200 CWE-863 CWE-22
Published
Advisory Summary

CVE-2026-56839 is a HIGH (CVSS 7.3) praisonai code agent tools fail vulnerability (CWE-200: Exposure of Sensitive Information to an Unauthorized Actor) affecting Praisonai libraries in the PyPI ecosystem. The issue involves praisonai code agent tools fail open without a workspace boundary. Remediation is available by upgrading affected packages to version 4.6.59.

CVE-2026-56839 at a Glance

CVE Identifier CVE-2026-56839
GHSA Identifier GHSA-gcq3-mfvh-3x25
Severity HIGH
CVSS v3.1 Base Score 7.3
CWE Classification CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Affected Product Praisonai
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 7.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction Required (UI:R)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-56839

To remediate this vulnerability, upgrade all affected Praisonai dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

praisonai fixed: 4.6.59
pip install praisonai>=4.6.59
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show praisonai

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-56839, inspect your installed packages using pip:

pip show praisonai

Analyze the terminal output to locate any version of Praisonai in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.6.59), your application is affected.

Note: The pip show praisonai command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, where the product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. In Praisonai, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

# 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 = 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: ```bash PYTHONPATH=/path/to/PraisonAI/src/praisonai:/path/to/PraisonAI/src/praisonai-agents \ python poc_code_tools_workspace_bypass.py ``` Expected vulnerable result: ```text [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 default for the advertised agent-tool bundle and adjacent read/edit helpers. ## Affected-Version Sweep The same behavior was reproduced on: - current upstream main: `2f9677abb2ea68eab864ee8b6a828fd0141612e1` - `v4.6.57` - `v4.6.56` - `v4.6.10` - `v4.6.9` - `v4.5.128` - `v4.5.126` - `v3.9.26` - `v3.9.24` ## Suggested Fix Recommended fix: 1. Make every low-level file helper compute `effective_workspace = workspace or os.getcwd()` before resolving paths. 2. Make `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`. 3. Keep allowing absolute paths only when they resolve inside the effective workspace. 4. Add regression tests proving outside absolute paths are rejected before and after `set_workspace()`. 5. Consider failing closed if `CODE_TOOLS` is used before a workspace is configured, or log a warning when the default current working directory is used. ## Disclosure Route 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.

CVE-2026-56839 Affected Praisonai Versions

1 component(s)
Fixed Versions:
4.6.59
Product / Package Ecosystem Affected Versions Fixed Version
praisonai
PyPI
< 4.6.59
4.6.59

References

Frequently Asked Questions

What is CVE-2026-56839?
CVE-2026-56839 is a security vulnerability in Praisonai involving PraisonAI Code agent tools fail open without a workspace boundary under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.
Which Praisonai versions are affected?
Affected versions include releases prior to 4.6.59 across affected packages: praisonai.
What version fixes CVE-2026-56839?
Upgrading to 4.6.59 (or the latest patched release for your respective branch) resolves the vulnerability.
Is praisonai affected?
Yes, praisonai is affected in releases prior to 4.6.59. Upgrade your dependency to 4.6.59 or later.
What is the CVSS score of CVE-2026-56839?
CVE-2026-56839 has a CVSS v3.1 base score of 7.3 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N.
What CWE is associated with CVE-2026-56839?
CVE-2026-56839 is classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor (The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.).
How can I check PyPI dependencies for CVE-2026-56839?
Run the dependency tree command: 'pip show praisonai'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-gcq3-mfvh-3x25",
  "modified" : "2026-07-20T21:23:47Z",
  "published" : "2026-06-18T13:59:26Z",
  "aliases" : [ "CVE-2026-56839" ],
  "summary" : "PraisonAI Code agent tools fail open without a workspace boundary",
  "details" : "# PraisonAI Code agent tools fail open without a workspace boundary\n\n## Summary\n\nPraisonAI 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.\n\nThe 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.\n\n## Affected Components\n\n- Package: `praisonai`\n- Current upstream main tested: `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- Latest tested release: `v4.6.57`\n- Primary files:\n  - `src/praisonai/praisonai/code/agent_tools.py`\n  - `src/praisonai/praisonai/code/tools/read_file.py`\n  - `src/praisonai/praisonai/code/tools/search_replace.py`\n  - `src/praisonai/praisonai/code/tools/apply_diff.py`\n\n## Root Cause\n\n`agent_tools.py` initializes `_workspace_root` to `None` and passes it directly to lower-level helpers:\n\n```python\n_workspace_root: Optional[str] = None\n...\nresult = _read_file(..., workspace=_workspace_root)\n...\nresult = _search_replace(..., workspace=_workspace_root)\n```\n\nThe lower-level helpers only enforce containment if `workspace` is set:\n\n```python\nif workspace:\n    if not is_path_within_directory(abs_path, workspace):\n        return {\"success\": False, ...}\n```\n\nThe 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.\n\n## Local-Only Reproduction\n\nRun:\n\n```bash\nPYTHONPATH=/path/to/PraisonAI/src/praisonai:/path/to/PraisonAI/src/praisonai-agents \\\n  python poc_code_tools_workspace_bypass.py\n```\n\nExpected vulnerable result:\n\n```text\n[poc] HIT: CODE_TOOLS wrappers read and edit outside workspace when workspace is unset\n```\n\nThe 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.\n\nNo external services, model providers, or network access are used.\n\n## Impact\n\nIf 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.\n\nPractical impacts include:\n\n- reading host secrets or local configuration files accessible to the process user;\n- modifying arbitrary existing files when the attacker can supply or infer matching content for `code_search_replace` or `code_apply_diff`;\n- using `code_read_file` to first learn file content and then `code_apply_diff` to produce an exact modification;\n- bypassing the advertised workspace-boundary security posture unless the embedding application remembered to call `set_workspace()` first.\n\nThis 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.\n\n## Affected-Version Sweep\n\nThe same behavior was reproduced on:\n\n- current upstream main: `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- `v4.6.57`\n- `v4.6.56`\n- `v4.6.10`\n- `v4.6.9`\n- `v4.5.128`\n- `v4.5.126`\n- `v3.9.26`\n- `v3.9.24`\n\n## Suggested Fix\n\nRecommended fix:\n\n1. Make every low-level file helper compute `effective_workspace = workspace or os.getcwd()` before resolving paths.\n2. Make `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`.\n3. Keep allowing absolute paths only when they resolve inside the effective workspace.\n4. Add regression tests proving outside absolute paths are rejected before and after `set_workspace()`.\n5. Consider failing closed if `CODE_TOOLS` is used before a workspace is configured, or log a warning when the default current working directory is used.\n\n## Disclosure Route\n\nPraisonAI'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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "praisonai"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.6.59"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 4.6.57"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-gcq3-mfvh-3x25"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/MervinPraison/PraisonAI"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-200", "CWE-22", "CWE-863" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-18T13:59:26Z",
    "nvd_published_at" : null
  }
}