CVE-2026-47417: praisonai-platform: IDOR enables cross-tenant comment exfil
GHSA-cp4f-5m9r-5jc2 HIGH CISA: TRACK*PraisonAI Platform's comment API has a classic Insecure Direct Object Reference flaw where workspace membership checks don't validate that the target issue belongs to the requester's workspace, letting any authenticated user read or write comments across all tenants. For organizations running PraisonAI Platform in a multi-tenant configuration this means any workspace member can silently exfiltrate full issue comment threads—which routinely contain AI agent configurations, pasted API keys, customer PII, and internal triage notes—and inject arbitrary comments under their own identity into foreign issues with no audit trail in the victim workspace. EPSS data is unavailable for this newly published CVE, it is not in CISA KEV, and no standalone public exploit exists yet; however, the GitHub advisory provides complete reproduce steps requiring only a valid workspace token and a guessable issue UUID. Upgrade to praisonai-platform 0.1.4 immediately—companion advisories for AgentService, IssueService, ProjectService, and LabelService indicate this is a systemic authorization pattern failure across the entire platform, so treat the full API surface as suspect until all companions are resolved.
What is the risk?
High. CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Network-reachable, no user interaction required after initial authentication, low-privilege precondition. In multi-tenant AI agent platform deployments the blast radius covers 100% of issue comments across every tenant workspace given issue UUIDs. The attack is trivially reproducible from the advisory's exploit chain. The 65 prior CVEs in the same package signal an elevated vulnerability history and weak authorization hygiene throughout the codebase. Unpatched multi-tenant instances are the sole risk surface; single-tenant self-hosted deployments face significantly lower exposure.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| PraisonAI | pip | < 0.1.4 | 0.1.4 |
Do you use PraisonAI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
5 steps-
Patch: upgrade praisonai-platform to >=0.1.4 immediately—the release adds
_require_issue_in_workspace()before all comment route handlers. -
Verify deployment: confirm the helper function is present in your deployed
src/praisonai-platform/praisonai_platform/api/routes/issues.pyat both the POST and GET comment handlers. -
Detect past exploitation: query your comments table for rows where the comment's
issue_idbelongs to a workspace different from the commenting user's known workspaces—these are indicators of prior exploitation. -
Audit companion surfaces: AgentService, IssueService, ProjectService, and LabelService have the same workspace-scoping gap per companion advisories—review all route handlers that accept external IDs against workspace-scoped DB queries before assuming containment.
-
Rotate secrets: if comments in your instance contained API keys, tokens, or credentials, treat them as compromised and rotate.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-47417?
PraisonAI Platform's comment API has a classic Insecure Direct Object Reference flaw where workspace membership checks don't validate that the target issue belongs to the requester's workspace, letting any authenticated user read or write comments across all tenants. For organizations running PraisonAI Platform in a multi-tenant configuration this means any workspace member can silently exfiltrate full issue comment threads—which routinely contain AI agent configurations, pasted API keys, customer PII, and internal triage notes—and inject arbitrary comments under their own identity into foreign issues with no audit trail in the victim workspace. EPSS data is unavailable for this newly published CVE, it is not in CISA KEV, and no standalone public exploit exists yet; however, the GitHub advisory provides complete reproduce steps requiring only a valid workspace token and a guessable issue UUID. Upgrade to praisonai-platform 0.1.4 immediately—companion advisories for AgentService, IssueService, ProjectService, and LabelService indicate this is a systemic authorization pattern failure across the entire platform, so treat the full API surface as suspect until all companions are resolved.
Is CVE-2026-47417 actively exploited?
No confirmed active exploitation of CVE-2026-47417 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-47417?
1. Patch: upgrade praisonai-platform to >=0.1.4 immediately—the release adds `_require_issue_in_workspace()` before all comment route handlers. 2. Verify deployment: confirm the helper function is present in your deployed `src/praisonai-platform/praisonai_platform/api/routes/issues.py` at both the POST and GET comment handlers. 3. Detect past exploitation: query your comments table for rows where the comment's `issue_id` belongs to a workspace different from the commenting user's known workspaces—these are indicators of prior exploitation. 4. Audit companion surfaces: AgentService, IssueService, ProjectService, and LabelService have the same workspace-scoping gap per companion advisories—review all route handlers that accept external IDs against workspace-scoped DB queries before assuming containment. 5. Rotate secrets: if comments in your instance contained API keys, tokens, or credentials, treat them as compromised and rotate.
What systems are affected by CVE-2026-47417?
This vulnerability affects the following AI/ML architecture patterns: AI agent platforms, Multi-tenant SaaS deployments, Agent orchestration frameworks, Issue tracking integrations for AI workflows.
What is the CVSS score for CVE-2026-47417?
CVE-2026-47417 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.21%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0025 Exfiltration via Cyber Means AML.T0036 Data from Information Repositories AML.T0048.001 Reputational Harm AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
What are the technical details?
Original Advisory
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. The comment endpoints (`POST /workspaces/{workspace_id}/issues/{issue_id}/comments` and `GET .../comments`) gate access on `require_workspace_member(workspace_id)` only, then call `CommentService.create(issue_id=issue_id, ...)` and `CommentService.list_for_issue(issue_id)` without verifying that `issue_id` belongs to `workspace_id`. A user who is a member of any workspace `W1` can read every comment on, and post new comments to, any issue in any other workspace `W2`. PraisonAI Platform version 0.1.4 patches the issue.
Exploitation Scenario
An adversary conducting competitive intelligence against an AI startup using PraisonAI Platform registers a free-tier workspace account. Using the platform's activity feed or webhook payloads visible within their own workspace they collect target issue UUIDs belonging to competitor workspaces. They loop through `GET /workspaces/{their_workspace}/issues/{target_issue_id}/comments` for each harvested UUID—the membership check passes on their workspace, no join is performed, and full comment threads are returned including bug reports with embedded API credentials, customer PII, and AI agent system prompt drafts. They follow up with `POST /workspaces/{their_workspace}/issues/{target_issue_id}/comments` injecting phishing links into high-traffic issues, targeting the victim's engineering team with credential-harvesting payloads that render as internal comments from a legitimate-looking author. The foreign workspace sees no membership change, no audit event, and no alert—the entire operation is invisible to the victim.
Weaknesses (CWE)
CWE-639 Authorization Bypass Through User-Controlled Key
Primary
CWE-639 Authorization Bypass Through User-Controlled Key
Primary
CWE-639 Authorization Bypass Through User-Controlled Key CWE-639 — Authorization Bypass Through User-Controlled Key: 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.
- [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N References
Timeline
Related Vulnerabilities
CVE-2026-61447 10.0 PraisonAI: RCE via unsandboxed LLM code execution
Same package: praisonai CVE-2026-61445 9.9 PraisonAI: AICoder root RCE via unsanitized tool calls
Same package: praisonai CVE-2026-47392 9.9 praisonaiagents: RCE via Python sandbox bypass
Same package: praisonai GHSA-vmmj-pfw7-fjwp 9.9 praisonai: sandbox escape gives RCE via codeMode tool
Same package: praisonai GHSA-vc46-vw85-3wvm 9.8 PraisonAI: RCE via malicious workflow YAML execution
Same package: praisonai