{
  "affected": [
    {
      "affectedData": [
        {
          "product": "praisonai-platform",
          "vendor": "MervinPraison",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.1.4"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an Insecure Direct Object Reference. Five label endpoints \u2014 `PATCH /workspaces/{workspace_id}/labels/{label_id}`, `DELETE .../labels/{label_id}`, `POST .../issues/{issue_id}/labels/{label_id}`, `DELETE .../issues/{issue_id}/labels/{label_id}`, `GET .../issues/{issue_id}/labels` \u2014 gate access on `require_workspace_member(workspace_id)` only and pass URL-supplied `label_id` and `issue_id` straight through to `LabelService` without verifying either belongs to the workspace. PraisonAI Platform version 0.1.4 patches the issue."
    },
    {
      "lang": "es",
      "value": "PraisonAI Platform es la capa de plataforma para el sistema de equipos multiagente de PraisonAI. Las versiones anteriores a la 0.1.4 tienen una Referencia Directa Insegura a Objeto. Cinco puntos finales de etiqueta - \u2019PATCH /workspaces/{workspace_id}/labels/{label_id}\u2019, \u2019DELETE ... / labels/{label_id}\u2019, \u2019POST ... / issues/{issue_id}/labels/{label_id}\u2019, \u2019DELETE ... / issues/{issue_id}/labels/{label_id}\u2019, \u2019GET ... / issues/{issue_id}/labels\u2019 - restringen el acceso a \u2019require_workspace_member(workspace_id)\u2019 solamente y pasan \u2019label_id\u2019 e \u2019issue_id\u2019 suministrados por la URL directamente a \u2019LabelService\u2019 sin verificar que ninguno de ellos pertenezca al espacio de trabajo. La versi\u00f3n 0.1.4 de PraisonAI Platform parchea el problema."
    }
  ],
  "id": "CVE-2026-47414",
  "lastModified": "2026-10-24T19:10:00.127",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "LOW",
          "baseScore": 7.6,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "LOW",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 4.7,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-47414",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-07-23T14:24:36.320353Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-07-21T18:17:00.283",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/MervinPraison/PraisonAI/commit/ef79b7a0561796ad9807f0f09538c25cc78d3619"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/MervinPraison/PraisonAI/pull/1685"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5jx9-w35f-vp65"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5jx9-w35f-vp65"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-639"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai-platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:51:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n**Type:** Insecure Direct Object Reference. Five label endpoints \u2014 `PATCH /workspaces/{workspace_id}/labels/{label_id}`, `DELETE .../labels/{label_id}`, `POST .../issues/{issue_id}/labels/{label_id}`, `DELETE .../issues/{issue_id}/labels/{label_id}`, `GET .../issues/{issue_id}/labels` \u2014 gate access on `require_workspace_member(workspace_id)` only and pass URL-supplied `label_id` and `issue_id` straight through to `LabelService` without verifying either belongs to the workspace.\n**File:** `src/praisonai-platform/praisonai_platform/services/label_service.py`, lines 35-100; route handlers at `src/praisonai-platform/praisonai_platform/api/routes/labels.py`, lines 42-106.\n**Root cause:** identical pattern to the agent / issue / project / comment IDORs in this codebase: the route\u0027s `workspace_id` is used as a membership predicate but never threaded through to the service layer. `LabelService.get(label_id)` runs `session.get(IssueLabel, label_id)` with no workspace filter; `update`/`delete` inherit the gap; `add_to_issue(issue_id, label_id)` and `remove_from_issue(issue_id, label_id)` write/delete association rows without verifying either ID belongs to the membership-checked workspace; `list_for_issue(issue_id)` reads them.\n\n## Affected Code\n\n**File 1:** `src/praisonai-platform/praisonai_platform/services/label_service.py`, lines 35-100.\n\n```python\nclass LabelService:\n    ...\n\n    async def get(self, label_id: str) -\u003e Optional[IssueLabel]:\n        return await self._session.get(IssueLabel, label_id)         # \u003c-- BUG: no workspace_id predicate\n\n    async def update(\n        self,\n        label_id: str,\n        ...\n    ) -\u003e Optional[IssueLabel]:\n        label = await self.get(label_id)                             # \u003c-- inherits the gap\n        ...\n\n    async def delete(self, label_id: str) -\u003e bool:\n        label = await self.get(label_id)                             # \u003c-- inherits the gap\n        ...\n\n    async def add_to_issue(self, issue_id: str, label_id: str) -\u003e None:\n        # writes a row in issue_label association table; no workspace check on either id\n\n    async def remove_from_issue(self, issue_id: str, label_id: str) -\u003e None:\n        # deletes from association table; no workspace check on either id\n\n    async def list_for_issue(self, issue_id: str) -\u003e list[IssueLabel]:\n        # reads from association table; no workspace check on issue_id\n```\n\n**File 2:** `src/praisonai-platform/praisonai_platform/api/routes/labels.py`, lines 42-106.\n\n```python\n@router.patch(\"/labels/{label_id}\", response_model=LabelResponse)\nasync def update_label(workspace_id: str, label_id: str, body: LabelUpdate, ...):\n    svc = LabelService(session)\n    label = await svc.update(label_id, body.name, body.color)        # \u003c-- writes any label in the DB\n    ...\n\n@router.delete(\"/labels/{label_id}\", ...)\nasync def delete_label(workspace_id: str, label_id: str, ...):\n    deleted = await svc.delete(label_id)                             # \u003c-- deletes any label in the DB\n    ...\n\n@router.post(\"/issues/{issue_id}/labels/{label_id}\", ...)\nasync def add_label_to_issue(workspace_id: str, issue_id: str, label_id: str, ...):\n    await svc.add_to_issue(issue_id, label_id)                       # \u003c-- attaches any label to any issue cross-workspace\n\n@router.delete(\"/issues/{issue_id}/labels/{label_id}\", ...)\nasync def remove_label_from_issue(workspace_id: str, issue_id: str, label_id: str, ...):\n    await svc.remove_from_issue(issue_id, label_id)                  # \u003c-- detaches any label from any issue cross-workspace\n\n@router.get(\"/issues/{issue_id}/labels\", ...)\nasync def list_issue_labels(workspace_id: str, issue_id: str, ...):\n    labels = await svc.list_for_issue(issue_id)                      # \u003c-- reads label assignments for any issue\n```\n\n**Why it\u0027s wrong:** the `workspace_id` URL segment is treated as a UI hint; the actual `label_id` and `issue_id` lookups query the database without a workspace constraint. The `MemberService` in this same codebase uses a composite key correctly; the label service does not. The `add_to_issue` and `remove_from_issue` paths are particularly nasty because they touch *two* unverified IDs at once: an attacker can attach a foreign workspace\u0027s label to a foreign workspace\u0027s issue (or detach the legitimate labels), corrupting both sides of an association the attacker has no business touching.\n\n## Exploit Chain\n\n1. Attacker registers a workspace `W_attacker` (member) and harvests a foreign-workspace `label_id` `L_T` and a foreign-workspace `issue_id` `I_T`. Both leak via `list_labels` responses (which include label IDs \u2014 but only for `W_attacker`; for the target the IDs come from issue records that include label associations, activity feeds, exported dumps, error messages). State: attacker holds `L_T` and `I_T`.\n2. Attacker authenticates and sends `PATCH /workspaces/W_attacker/labels/L_T` with `{\"name\": \"\u003cdeleted\u003e\", \"color\": \"#000000\"}`. `require_workspace_member(W_attacker, attacker)` passes. `LabelService.update(L_T, ...)` loads the foreign label and renames it. State: every issue across the foreign workspace that bears this label now displays the attacker-chosen name and colour.\n3. Attacker sends `DELETE /workspaces/W_attacker/labels/L_T`. `LabelService.delete(L_T)` deletes the foreign label, dropping every issue-label association row that referenced it (cascade or orphan, depending on schema). State: foreign workspace\u0027s labels are gone or corrupted.\n4. Attacker sends `POST /workspaces/W_attacker/issues/I_T/labels/L_T2` to attach foreign label `L_T2` to foreign issue `I_T`. `LabelService.add_to_issue(I_T, L_T2)` writes the association row regardless of either ID\u0027s workspace. State: the foreign issue now carries an arbitrary attacker-chosen label, which surfaces in every filter/search/board view in the foreign workspace\u0027s UI.\n5. Attacker sends `DELETE /workspaces/W_attacker/issues/I_T/labels/L_legit` to strip the legitimate label off the foreign issue. State: triagers can no longer find the issue via label filters.\n6. Attacker sends `GET /workspaces/W_attacker/issues/I_T/labels` to read the current label set on any foreign issue. State: the attacker fingerprints the foreign workspace\u0027s triage taxonomy.\n7. Final state: with one workspace-member token plus harvested foreign IDs, the attacker rewrites and deletes other workspaces\u0027 labels, attaches/detaches arbitrary labels on other workspaces\u0027 issues, and reads triage state across the deployment.\n\n## Security Impact\n\n**Severity:** sec-moderate. CVSS 6.3: network attack, low complexity, low privileges, no user interaction, scope unchanged. The integrity damage is high (rename/delete of foreign labels is permanent and silent; cross-workspace label-attachment corrupts UI filters), confidentiality is low (label names are not the most sensitive field but do leak triage taxonomy), availability low (foreign workspaces may lose triage visibility into their own issues until the labels are restored).\n**Attacker capability:** rename and delete any label in the multi-tenant deployment; attach any label to any issue; detach any label from any issue; list label assignments for any issue. Combined with the companion `IssueService` IDOR (separate advisory), the attacker can also modify the underlying issue, making the cross-workspace tampering very difficult to detect.\n**Preconditions:** `praisonai-platform` is deployed multi-tenant; the attacker has any membership token; target IDs are known or guessable.\n**Differential:** source-inspection-verified end-to-end. The asymmetry between `LabelService.list_for_workspace(workspace_id)` (correctly workspace-scoped) and `LabelService.get(label_id) / add_to_issue(issue_id, label_id)` (no workspace check) confirms the gap. With the suggested fix below, label and issue IDs that do not belong to the membership-checked workspace return 404, and the attacker cannot touch them.\n\n## Suggested Fix\n\nMake every single-row label lookup take the workspace predicate; verify both `issue_id` and `label_id` belong to `workspace_id` for the association routes.\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/services/label_service.py\n+++ b/src/praisonai-platform/praisonai_platform/services/label_service.py\n@@ -33,7 +33,12 @@ class LabelService:\n         return label\n\n-    async def get(self, label_id: str) -\u003e Optional[IssueLabel]:\n-        return await self._session.get(IssueLabel, label_id)\n+    async def get(self, workspace_id: str, label_id: str) -\u003e Optional[IssueLabel]:\n+        stmt = select(IssueLabel).where(\n+            IssueLabel.id == label_id,\n+            IssueLabel.workspace_id == workspace_id,\n+        )\n+        return (await self._session.execute(stmt)).scalar_one_or_none()\n\n-    async def add_to_issue(self, issue_id: str, label_id: str) -\u003e None:\n+    async def add_to_issue(self, workspace_id: str, issue_id: str, label_id: str) -\u003e None:\n+        # Verify both ids belong to workspace_id before writing the association row.\n```\n\nThen update the route handlers in `routes/labels.py` to thread `workspace_id` through every call. The same single-key-lookup pattern is filed separately for `AgentService`, `IssueService`, `ProjectService`, and `CommentService` \u2014 each is its own exploitable IDOR.",
  "id": "GHSA-5jx9-w35f-vp65",
  "modified": "2026-05-29T22:51:07Z",
  "published": "2026-05-29T22:51:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5jx9-w35f-vp65"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "praisonai-platform: Label endpoints\u0027 unchecked label_id/issue_id enable cross-workspace label IDOR (edit, delete, link)"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai-platform",
        "purl": "pkg:pypi/praisonai-platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.1.0",
        "0.1.1",
        "0.1.2",
        "0.1.3"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47414",
    "GHSA-5jx9-w35f-vp65"
  ],
  "details": "## Summary\n\n**Type:** Insecure Direct Object Reference. Five label endpoints \u2014 `PATCH /workspaces/{workspace_id}/labels/{label_id}`, `DELETE .../labels/{label_id}`, `POST .../issues/{issue_id}/labels/{label_id}`, `DELETE .../issues/{issue_id}/labels/{label_id}`, `GET .../issues/{issue_id}/labels` \u2014 gate access on `require_workspace_member(workspace_id)` only and pass URL-supplied `label_id` and `issue_id` straight through to `LabelService` without verifying either belongs to the workspace.\n**File:** `src/praisonai-platform/praisonai_platform/services/label_service.py`, lines 35-100; route handlers at `src/praisonai-platform/praisonai_platform/api/routes/labels.py`, lines 42-106.\n**Root cause:** identical pattern to the agent / issue / project / comment IDORs in this codebase: the route\u0027s `workspace_id` is used as a membership predicate but never threaded through to the service layer. `LabelService.get(label_id)` runs `session.get(IssueLabel, label_id)` with no workspace filter; `update`/`delete` inherit the gap; `add_to_issue(issue_id, label_id)` and `remove_from_issue(issue_id, label_id)` write/delete association rows without verifying either ID belongs to the membership-checked workspace; `list_for_issue(issue_id)` reads them.\n\n## Affected Code\n\n**File 1:** `src/praisonai-platform/praisonai_platform/services/label_service.py`, lines 35-100.\n\n```python\nclass LabelService:\n    ...\n\n    async def get(self, label_id: str) -\u003e Optional[IssueLabel]:\n        return await self._session.get(IssueLabel, label_id)         # \u003c-- BUG: no workspace_id predicate\n\n    async def update(\n        self,\n        label_id: str,\n        ...\n    ) -\u003e Optional[IssueLabel]:\n        label = await self.get(label_id)                             # \u003c-- inherits the gap\n        ...\n\n    async def delete(self, label_id: str) -\u003e bool:\n        label = await self.get(label_id)                             # \u003c-- inherits the gap\n        ...\n\n    async def add_to_issue(self, issue_id: str, label_id: str) -\u003e None:\n        # writes a row in issue_label association table; no workspace check on either id\n\n    async def remove_from_issue(self, issue_id: str, label_id: str) -\u003e None:\n        # deletes from association table; no workspace check on either id\n\n    async def list_for_issue(self, issue_id: str) -\u003e list[IssueLabel]:\n        # reads from association table; no workspace check on issue_id\n```\n\n**File 2:** `src/praisonai-platform/praisonai_platform/api/routes/labels.py`, lines 42-106.\n\n```python\n@router.patch(\"/labels/{label_id}\", response_model=LabelResponse)\nasync def update_label(workspace_id: str, label_id: str, body: LabelUpdate, ...):\n    svc = LabelService(session)\n    label = await svc.update(label_id, body.name, body.color)        # \u003c-- writes any label in the DB\n    ...\n\n@router.delete(\"/labels/{label_id}\", ...)\nasync def delete_label(workspace_id: str, label_id: str, ...):\n    deleted = await svc.delete(label_id)                             # \u003c-- deletes any label in the DB\n    ...\n\n@router.post(\"/issues/{issue_id}/labels/{label_id}\", ...)\nasync def add_label_to_issue(workspace_id: str, issue_id: str, label_id: str, ...):\n    await svc.add_to_issue(issue_id, label_id)                       # \u003c-- attaches any label to any issue cross-workspace\n\n@router.delete(\"/issues/{issue_id}/labels/{label_id}\", ...)\nasync def remove_label_from_issue(workspace_id: str, issue_id: str, label_id: str, ...):\n    await svc.remove_from_issue(issue_id, label_id)                  # \u003c-- detaches any label from any issue cross-workspace\n\n@router.get(\"/issues/{issue_id}/labels\", ...)\nasync def list_issue_labels(workspace_id: str, issue_id: str, ...):\n    labels = await svc.list_for_issue(issue_id)                      # \u003c-- reads label assignments for any issue\n```\n\n**Why it\u0027s wrong:** the `workspace_id` URL segment is treated as a UI hint; the actual `label_id` and `issue_id` lookups query the database without a workspace constraint. The `MemberService` in this same codebase uses a composite key correctly; the label service does not. The `add_to_issue` and `remove_from_issue` paths are particularly nasty because they touch *two* unverified IDs at once: an attacker can attach a foreign workspace\u0027s label to a foreign workspace\u0027s issue (or detach the legitimate labels), corrupting both sides of an association the attacker has no business touching.\n\n## Exploit Chain\n\n1. Attacker registers a workspace `W_attacker` (member) and harvests a foreign-workspace `label_id` `L_T` and a foreign-workspace `issue_id` `I_T`. Both leak via `list_labels` responses (which include label IDs \u2014 but only for `W_attacker`; for the target the IDs come from issue records that include label associations, activity feeds, exported dumps, error messages). State: attacker holds `L_T` and `I_T`.\n2. Attacker authenticates and sends `PATCH /workspaces/W_attacker/labels/L_T` with `{\"name\": \"\u003cdeleted\u003e\", \"color\": \"#000000\"}`. `require_workspace_member(W_attacker, attacker)` passes. `LabelService.update(L_T, ...)` loads the foreign label and renames it. State: every issue across the foreign workspace that bears this label now displays the attacker-chosen name and colour.\n3. Attacker sends `DELETE /workspaces/W_attacker/labels/L_T`. `LabelService.delete(L_T)` deletes the foreign label, dropping every issue-label association row that referenced it (cascade or orphan, depending on schema). State: foreign workspace\u0027s labels are gone or corrupted.\n4. Attacker sends `POST /workspaces/W_attacker/issues/I_T/labels/L_T2` to attach foreign label `L_T2` to foreign issue `I_T`. `LabelService.add_to_issue(I_T, L_T2)` writes the association row regardless of either ID\u0027s workspace. State: the foreign issue now carries an arbitrary attacker-chosen label, which surfaces in every filter/search/board view in the foreign workspace\u0027s UI.\n5. Attacker sends `DELETE /workspaces/W_attacker/issues/I_T/labels/L_legit` to strip the legitimate label off the foreign issue. State: triagers can no longer find the issue via label filters.\n6. Attacker sends `GET /workspaces/W_attacker/issues/I_T/labels` to read the current label set on any foreign issue. State: the attacker fingerprints the foreign workspace\u0027s triage taxonomy.\n7. Final state: with one workspace-member token plus harvested foreign IDs, the attacker rewrites and deletes other workspaces\u0027 labels, attaches/detaches arbitrary labels on other workspaces\u0027 issues, and reads triage state across the deployment.\n\n## Security Impact\n\n**Severity:** sec-moderate. CVSS 6.3: network attack, low complexity, low privileges, no user interaction, scope unchanged. The integrity damage is high (rename/delete of foreign labels is permanent and silent; cross-workspace label-attachment corrupts UI filters), confidentiality is low (label names are not the most sensitive field but do leak triage taxonomy), availability low (foreign workspaces may lose triage visibility into their own issues until the labels are restored).\n**Attacker capability:** rename and delete any label in the multi-tenant deployment; attach any label to any issue; detach any label from any issue; list label assignments for any issue. Combined with the companion `IssueService` IDOR (separate advisory), the attacker can also modify the underlying issue, making the cross-workspace tampering very difficult to detect.\n**Preconditions:** `praisonai-platform` is deployed multi-tenant; the attacker has any membership token; target IDs are known or guessable.\n**Differential:** source-inspection-verified end-to-end. The asymmetry between `LabelService.list_for_workspace(workspace_id)` (correctly workspace-scoped) and `LabelService.get(label_id) / add_to_issue(issue_id, label_id)` (no workspace check) confirms the gap. With the suggested fix below, label and issue IDs that do not belong to the membership-checked workspace return 404, and the attacker cannot touch them.\n\n## Suggested Fix\n\nMake every single-row label lookup take the workspace predicate; verify both `issue_id` and `label_id` belong to `workspace_id` for the association routes.\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/services/label_service.py\n+++ b/src/praisonai-platform/praisonai_platform/services/label_service.py\n@@ -33,7 +33,12 @@ class LabelService:\n         return label\n\n-    async def get(self, label_id: str) -\u003e Optional[IssueLabel]:\n-        return await self._session.get(IssueLabel, label_id)\n+    async def get(self, workspace_id: str, label_id: str) -\u003e Optional[IssueLabel]:\n+        stmt = select(IssueLabel).where(\n+            IssueLabel.id == label_id,\n+            IssueLabel.workspace_id == workspace_id,\n+        )\n+        return (await self._session.execute(stmt)).scalar_one_or_none()\n\n-    async def add_to_issue(self, issue_id: str, label_id: str) -\u003e None:\n+    async def add_to_issue(self, workspace_id: str, issue_id: str, label_id: str) -\u003e None:\n+        # Verify both ids belong to workspace_id before writing the association row.\n```\n\nThen update the route handlers in `routes/labels.py` to thread `workspace_id` through every call. The same single-key-lookup pattern is filed separately for `AgentService`, `IssueService`, `ProjectService`, and `CommentService` \u2014 each is its own exploitable IDOR.",
  "id": "PYSEC-2026-2929",
  "modified": "2026-07-13T16:05:37.729729Z",
  "published": "2026-07-13T15:35:22.424643Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5jx9-w35f-vp65"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/praisonai-platform"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-5jx9-w35f-vp65"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47414"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "praisonai-platform: Label endpoints\u0027 unchecked label_id/issue_id enable cross-workspace label IDOR (edit, delete, link)"
}