CVE-2026-47415: praisonai-platform Issue Endpoints Accept Any Issue_id Vulnerability
HIGHCVE-2026-47415 is a HIGH (CVSS 8.3) issue endpoints accept any issue_id vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting praisonai-platform libraries in the PyPI ecosystem. The issue involves issue endpoints accept any issue_id without workspace ownership check, cross-workspace read/update/delete idor. Remediation is available by upgrading affected packages to version 0.1.4.
CVE-2026-47415 at a Glance
Security Impact
CVSS: 8.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:N/S:U/C:H/I:H/A:L).
How to Fix CVE-2026-47415
To remediate this vulnerability, upgrade all affected praisonai-platform dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
pip install praisonai-platform>=0.1.4
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
pip show praisonai-platform
How to Check if You Are Affected
To determine whether your Python environment is affected by CVE-2026-47415, inspect your installed packages using pip:
pip show praisonai-platform
Analyze the terminal output to locate any version of praisonai-platform in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.1.4), your application is affected.
Note: The pip show praisonai-platform command checks currently installed packages in your active Python environment.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, where the system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. In praisonai-platform, 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
CVE-2026-47415 Affected praisonai-platform Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
praisonai-platform
|
PyPI |
< 0.1.4
|
0.1.4
|
References
Frequently Asked Questions
What is CVE-2026-47415?
Which praisonai-platform versions are affected?
What version fixes CVE-2026-47415?
Is praisonai-platform affected?
What is the CVSS score of CVE-2026-47415?
What CWE is associated with CVE-2026-47415?
How can I check PyPI dependencies for CVE-2026-47415?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-xwq8-frcg-77q8",
"modified" : "2026-06-01T14:24:12Z",
"published" : "2026-06-01T14:24:12Z",
"aliases" : [ "CVE-2026-47415" ],
"summary" : "praisonai-platform: Issue endpoints accept any issue_id without workspace ownership check, cross-workspace read/update/delete IDOR",
"details" : "## Summary\n\n**Type:** Insecure Direct Object Reference. The issue CRUD endpoints (`GET / PATCH / DELETE /workspaces/{workspace_id}/issues/{issue_id}`) gate access on `require_workspace_member(workspace_id)` only, then resolve `issue_id` through `IssueService.get(issue_id)` which is a primary-key lookup with no workspace constraint. A user who is a member of any workspace `W1` can read, modify, or delete issues that belong to a different workspace `W2`.\n**File:** `src/praisonai-platform/praisonai_platform/services/issue_service.py`, lines 72-156; route handlers at `src/praisonai-platform/praisonai_platform/api/routes/issues.py`, lines 82-137.\n**Root cause:** the route extracts `workspace_id` from the URL path, uses it solely for the membership gate, then calls `IssueService.get(issue_id)` / `IssueService.update(issue_id, ...)` / `IssueService.delete(issue_id)` without re-checking which workspace the issue actually belongs to. `IssueService.get` runs a single-key lookup; `update` and `delete` call `self.get(issue_id)` first and then mutate the returned row, inheriting the same gap. The `MemberService` in this same codebase uses a composite `(workspace_id, user_id)` key, proving the author knows the safe pattern; it was simply not applied to the issue, agent, project, comment, or label services.\n\n## Affected Code\n\n**File 1:** `src/praisonai-platform/praisonai_platform/services/issue_service.py`, lines 72-75 and 97-156.\n\n```python\nclass IssueService:\n ...\n\n async def get(self, issue_id: str) -> Optional[Issue]:\n \"\"\"Get issue by ID.\"\"\"\n return await self._session.get(Issue, issue_id) # <-- BUG: no workspace_id predicate\n\n async def update(\n self,\n issue_id: str,\n title: Optional[str] = None,\n ...\n ) -> Optional[Issue]:\n issue = await self.get(issue_id) # <-- inherits the same gap\n if issue is None:\n return None\n ...\n return issue\n\n async def delete(self, issue_id: str) -> bool:\n issue = await self.get(issue_id) # <-- inherits the same gap\n if issue is None:\n return False\n await self._session.delete(issue)\n await self._session.flush()\n return True\n```\n\n**File 2:** `src/praisonai-platform/praisonai_platform/api/routes/issues.py`, lines 82-137.\n\n```python\n@router.get(\"/{issue_id}\", response_model=IssueResponse)\nasync def get_issue(\n workspace_id: str,\n issue_id: str,\n user: AuthIdentity = Depends(require_workspace_member), # only checks membership in workspace_id\n session: AsyncSession = Depends(get_db),\n):\n svc = IssueService(session)\n issue = await svc.get(issue_id) # <-- workspace_id never threaded through\n if issue is None:\n raise HTTPException(status_code=404, detail=\"Issue not found\")\n return IssueResponse.model_validate(issue)\n\n\n@router.patch(\"/{issue_id}\", response_model=IssueResponse)\nasync def update_issue(\n workspace_id: str,\n issue_id: str,\n body: IssueUpdate,\n user: AuthIdentity = Depends(require_workspace_member),\n session: AsyncSession = Depends(get_db),\n):\n svc = IssueService(session)\n issue = await svc.update( # <-- writes to any issue in the DB\n issue_id, title=body.title, description=body.description,\n status=body.status, priority=body.priority,\n assignee_type=body.assignee_type, assignee_id=body.assignee_id,\n project_id=body.project_id,\n )\n ...\n```\n\n`delete_issue` (lines 127-137) repeats the pattern.\n\n**Why it's wrong:** `workspace_id` from the route is used solely as a membership predicate (\"are you in some workspace W?\"), never as a resource-ownership predicate (\"is the issue you are addressing actually inside W?\"). The standard FastAPI/SQLAlchemy fix is to make the resource-lookup query include the workspace constraint and treat absence as 404, so a foreign-workspace issue is indistinguishable from a non-existent one. The `update_issue` handler additionally allows the attacker to overwrite `project_id`, which can re-assign the foreign issue to an unrelated project the attacker also does not own — escalating the scope of the write primitive.\n\n## Exploit Chain\n\n1. Attacker registers a workspace `W_attacker` (where they are a member) and harvests a target issue UUID `I_T` from any side channel: the activity feed (`activity.py:log` records `issue_id=...`), comment threads, error messages, exported issue dumps, issue mentions in agent prompts, or operator screenshots. Issue IDs are uuid4 strings but they are not secret. State: attacker holds `I_T`.\n2. Attacker authenticates and POSTs `Authorization: Bearer <attacker_jwt>` to `GET /workspaces/W_attacker/issues/I_T`. `require_workspace_member(W_attacker, attacker)` passes (attacker is a member of `W_attacker`). State: control flow enters `get_issue` with `workspace_id=W_attacker, issue_id=I_T`.\n3. `IssueService.get(I_T)` runs `session.get(Issue, \"I_T\")`, which is `SELECT * FROM issues WHERE id = 'I_T' LIMIT 1` with no `workspace_id = 'W_attacker'` filter. The row is returned in full — including `title`, `description` (often confidential bug-report content, customer PII, embedded credentials, or internal roadmap data), `status`, `priority`, `assignee_id`, `created_by`, and `project_id`. State: response body is the JSON-serialised foreign issue.\n4. Attacker repeats with `PATCH /workspaces/W_attacker/issues/I_T` and a body of `{\"description\": \"<reset>\", \"status\": \"closed\", \"project_id\": \"<arbitrary>\"}`. `update_issue` calls `svc.update(I_T, ...)` which loads the target row and mutates the listed fields. State: the foreign workspace's issue is silently re-described, re-statused, and re-projected.\n5. Attacker calls `DELETE /workspaces/W_attacker/issues/I_T` to destroy the target issue. `IssueService.delete` loads the row and calls `session.delete()`. State: target issue is gone from the foreign workspace.\n6. Final state: any attacker with one workspace-member token can enumerate, exfiltrate, rewrite, and delete every issue in the multi-tenant deployment given the issue UUIDs (which leak through the side channels above). The `act_svc.log(workspace_id, \"issue.updated\", \"issue\", issue.id, ...)` call at line 118 records the event under `W_attacker` rather than `W_target`, so the foreign workspace's audit trail does not record the tampering — making detection harder.\n\n## Security Impact\n\n**Severity:** sec-high. CVSS 8.1: network attack, low complexity, low privileges (any workspace member), no user interaction, scope unchanged, high confidentiality (full issue body including any embedded secrets), high integrity (arbitrary writes including project re-assignment), low availability (DELETE wipes target issues).\n**Attacker capability:** with one workspace-member token plus a harvested issue UUID, an attacker reads the target issue's `title`, `description`, `status`, `priority`, `assignee_id`, and `project_id`; rewrites any of those fields (silent edit, false closure, malicious re-assignment); re-projects the issue to an unrelated project to confuse triagers; or deletes the issue altogether to destroy evidence of customer reports.\n**Preconditions:** `praisonai-platform` is deployed multi-tenant; the attacker has any membership token; the target issue's UUID is known or guessable (UUIDs leak through activity feeds, comment threads, error messages, exported dumps, and operator screenshots).\n**Differential:** source-inspection-verified end-to-end. The asymmetry between `IssueService.get(issue_id)` (no workspace check) and `MemberService.get(workspace_id, user_id)` (composite key check) in the same codebase confirms the pattern. With the suggested fix below applied, `IssueService.get(workspace_id, issue_id)` returns `None` for foreign-workspace issues, the route handler returns 404, and the foreign data is indistinguishable from a missing record.\n\n## Suggested Fix\n\nMake every single-row resource lookup take the workspace predicate; treat foreign-workspace rows as 404.\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/services/issue_service.py\n+++ b/src/praisonai-platform/praisonai_platform/services/issue_service.py\n@@ -69,9 +69,12 @@ class IssueService:\n await self._session.flush()\n return issue\n\n- async def get(self, issue_id: str) -> Optional[Issue]:\n- \"\"\"Get issue by ID.\"\"\"\n- return await self._session.get(Issue, issue_id)\n+ async def get(self, workspace_id: str, issue_id: str) -> Optional[Issue]:\n+ \"\"\"Get issue by ID, scoped to a workspace.\"\"\"\n+ stmt = select(Issue).where(\n+ Issue.id == issue_id, Issue.workspace_id == workspace_id\n+ )\n+ return (await self._session.execute(stmt)).scalar_one_or_none()\n\n async def update(\n self,\n+ workspace_id: str,\n issue_id: str,\n ...\n ) -> Optional[Issue]:\n- issue = await self.get(issue_id)\n+ issue = await self.get(workspace_id, issue_id)\n ...\n\n- async def delete(self, issue_id: str) -> bool:\n+ async def delete(self, workspace_id: str, issue_id: str) -> bool:\n- issue = await self.get(issue_id)\n+ issue = await self.get(workspace_id, issue_id)\n```\n\nUpdate the route handlers in `routes/issues.py` to thread `workspace_id` through. The same pattern (single-key resource lookup gated only by workspace-member check) exists in `AgentService`, `ProjectService`, `CommentService`, and `LabelService`; each is a separate exploitable IDOR and should be filed as its own advisory so each gets a CVE.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "PyPI",
"name" : "praisonai-platform"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "0.1.4"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-xwq8-frcg-77q8"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/MervinPraison/PraisonAI"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-639" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-06-01T14:24:12Z",
"nvd_published_at" : null
}
}