<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 28 Sep 2026 06:39:39 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-56839</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-56839</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-56839</guid>
    </item>
    <item>
      <title>GHSA-gcq3-mfvh-3x25 — PraisonAI Code agent tools fail open without a workspace boundary</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-gcq3-mfvh-3x25</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai&lt;/p&gt;
&lt;p&gt;# PraisonAI Code agent tools fail open without a workspace boundary&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;PraisonAI Code&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## Affected Components&lt;/p&gt;
&lt;p&gt;- 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`&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;`agent_tools.py` initializes `_workspac…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai&lt;/p&gt;
&lt;p&gt;# PraisonAI Code agent tools fail open without a workspace boundary&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;PraisonAI Code&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## Affected Components&lt;/p&gt;
&lt;p&gt;- 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`&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;`agent_tools.py` initializes `_workspac…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-gcq3-mfvh-3x25</guid>
    </item>
    <item>
      <title>PYSEC-2026-3512 — PraisonAI Code agent tools fail open without a workspace boundary</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-3512</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai&lt;/p&gt;
&lt;p&gt;# PraisonAI Code agent tools fail open without a workspace boundary&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;PraisonAI Code&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## Affected Components&lt;/p&gt;
&lt;p&gt;- 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`&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;`agent_tools.py` initializes `_workspac…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai&lt;/p&gt;
&lt;p&gt;# PraisonAI Code agent tools fail open without a workspace boundary&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;PraisonAI Code&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## Affected Components&lt;/p&gt;
&lt;p&gt;- 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`&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;`agent_tools.py` initializes `_workspac…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-3512</guid>
    </item>
  </channel>
</rss>
