<?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>Thu, 08 Oct 2026 23:53:27 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-47413</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-47413</link>
      <description>&lt;p&gt;PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have aprivilege escalation / cross-tenant member injection. The `POST /workspaces/{workspace_id}/members` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role=&amp;#34;member&amp;#34;`) and forwards the request body&amp;#39;s `user_id` and `role` straight into `MemberService.add(workspace_id, user_id, role)`, which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. PraisonAI Platform version 0.1.4 patches the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have aprivilege escalation / cross-tenant member injection. The `POST /workspaces/{workspace_id}/members` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role=&amp;#34;member&amp;#34;`) and forwards the request body&amp;#39;s `user_id` and `role` straight into `MemberService.add(workspace_id, user_id, role)`, which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. PraisonAI Platform version 0.1.4 patches the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-47413</guid>
    </item>
    <item>
      <title>GHSA-8g2p-pqm3-fcfh — praisonai-platform: Any workspace member can add arbitrary user as owner via POST /workspaces/{id}/members</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-8g2p-pqm3-fcfh</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai-platform&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;**Type:** Privilege escalation / cross-tenant member injection. The `POST /workspaces/{workspace_id}/members` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role=&amp;#34;member&amp;#34;`) and forwards the request body&amp;#39;s `user_id` and `role` straight into `MemberService.add(workspace_id, user_id, role)`, which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace.
**File:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 92-101; `services/member_service.py`, lines 26-38.
**Root cause:** `MemberService.add` validates only that `role` is in `VALID_ROLES = {&amp;#34;owner&amp;#34;, &amp;#34;admin&amp;#34;, &amp;#34;member&amp;#34;}` — the value, not the caller&amp;#39;s right to assign it. The route&amp;#39;s `Depends(require_workspace_member)` resolves to the default `min_role=&amp;#34;member&amp;#34;`. So a member-level token plus one POST gives the attacker an alternate identity with owner role inside the same workspace, bypassing every owner-only operation that *would* otherwise gate them.&lt;/p&gt;
&lt;p&gt;## Affected Code&lt;/p&gt;
&lt;p&gt;**File 1:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 92-101.&lt;/p&gt;
&lt;p&gt;```python
@router.post(&amp;#34;/{workspace_id}/members&amp;#34;, response_model=MemberResponse, status_code=status.HTTP_201_CREATED)
async def add_member(
    workspace_id: str,
    body: MemberAdd,
    user: AuthIdentity = Depends(require_workspace_memb…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai-platform&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;**Type:** Privilege escalation / cross-tenant member injection. The `POST /workspaces/{workspace_id}/members` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role=&amp;#34;member&amp;#34;`) and forwards the request body&amp;#39;s `user_id` and `role` straight into `MemberService.add(workspace_id, user_id, role)`, which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace.
**File:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 92-101; `services/member_service.py`, lines 26-38.
**Root cause:** `MemberService.add` validates only that `role` is in `VALID_ROLES = {&amp;#34;owner&amp;#34;, &amp;#34;admin&amp;#34;, &amp;#34;member&amp;#34;}` — the value, not the caller&amp;#39;s right to assign it. The route&amp;#39;s `Depends(require_workspace_member)` resolves to the default `min_role=&amp;#34;member&amp;#34;`. So a member-level token plus one POST gives the attacker an alternate identity with owner role inside the same workspace, bypassing every owner-only operation that *would* otherwise gate them.&lt;/p&gt;
&lt;p&gt;## Affected Code&lt;/p&gt;
&lt;p&gt;**File 1:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 92-101.&lt;/p&gt;
&lt;p&gt;```python
@router.post(&amp;#34;/{workspace_id}/members&amp;#34;, response_model=MemberResponse, status_code=status.HTTP_201_CREATED)
async def add_member(
    workspace_id: str,
    body: MemberAdd,
    user: AuthIdentity = Depends(require_workspace_memb…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-8g2p-pqm3-fcfh</guid>
    </item>
    <item>
      <title>PYSEC-2026-480 — praisonai-platform: Any workspace member can add arbitrary user as owner via POST /workspaces/{id}/members</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-480</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai-platform&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;**Type:** Privilege escalation / cross-tenant member injection. The `POST /workspaces/{workspace_id}/members` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role=&amp;#34;member&amp;#34;`) and forwards the request body&amp;#39;s `user_id` and `role` straight into `MemberService.add(workspace_id, user_id, role)`, which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace.
**File:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 92-101; `services/member_service.py`, lines 26-38.
**Root cause:** `MemberService.add` validates only that `role` is in `VALID_ROLES = {&amp;#34;owner&amp;#34;, &amp;#34;admin&amp;#34;, &amp;#34;member&amp;#34;}` — the value, not the caller&amp;#39;s right to assign it. The route&amp;#39;s `Depends(require_workspace_member)` resolves to the default `min_role=&amp;#34;member&amp;#34;`. So a member-level token plus one POST gives the attacker an alternate identity with owner role inside the same workspace, bypassing every owner-only operation that *would* otherwise gate them.&lt;/p&gt;
&lt;p&gt;## Affected Code&lt;/p&gt;
&lt;p&gt;**File 1:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 92-101.&lt;/p&gt;
&lt;p&gt;```python
@router.post(&amp;#34;/{workspace_id}/members&amp;#34;, response_model=MemberResponse, status_code=status.HTTP_201_CREATED)
async def add_member(
    workspace_id: str,
    body: MemberAdd,
    user: AuthIdentity = Depends(require_workspace_memb…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai-platform&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;**Type:** Privilege escalation / cross-tenant member injection. The `POST /workspaces/{workspace_id}/members` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role=&amp;#34;member&amp;#34;`) and forwards the request body&amp;#39;s `user_id` and `role` straight into `MemberService.add(workspace_id, user_id, role)`, which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace.
**File:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 92-101; `services/member_service.py`, lines 26-38.
**Root cause:** `MemberService.add` validates only that `role` is in `VALID_ROLES = {&amp;#34;owner&amp;#34;, &amp;#34;admin&amp;#34;, &amp;#34;member&amp;#34;}` — the value, not the caller&amp;#39;s right to assign it. The route&amp;#39;s `Depends(require_workspace_member)` resolves to the default `min_role=&amp;#34;member&amp;#34;`. So a member-level token plus one POST gives the attacker an alternate identity with owner role inside the same workspace, bypassing every owner-only operation that *would* otherwise gate them.&lt;/p&gt;
&lt;p&gt;## Affected Code&lt;/p&gt;
&lt;p&gt;**File 1:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 92-101.&lt;/p&gt;
&lt;p&gt;```python
@router.post(&amp;#34;/{workspace_id}/members&amp;#34;, response_model=MemberResponse, status_code=status.HTTP_201_CREATED)
async def add_member(
    workspace_id: str,
    body: MemberAdd,
    user: AuthIdentity = Depends(require_workspace_memb…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-480</guid>
    </item>
  </channel>
</rss>
