CVE-2026-58653: PraisonAI IDOR cross-tenant data

CISO Take

PraisonAI before version 0.1.7 fails to check that the project_id supplied in issue create/update API calls actually belongs to the workspace referenced in the URL, letting an authenticated low-privilege user write issues into projects owned by other tenants. This is a textbook broken-object-level-authorization (IDOR) flaw, rated medium (CVSS 4.3) precisely because the confirmed impact is limited to integrity — corrupted project statistics aggregation across tenant boundaries — with no confidentiality or availability loss and no privilege escalation to system control. There is no EPSS score, it is not in CISA KEV, and no public exploit code or Nuclei template exists, so this looks like a disclosed-but-unweaponized bug rather than an active threat; downstream dependent counts are unknown, so blast radius across the ecosystem can't be quantified. If you run PraisonAI as a multi-tenant service (agent workspaces, project/issue tracking for tenants), upgrade to 0.1.7+ now, and in the meantime audit issue records for project_id values that don't match their owning workspace and flag any statistics anomalies for review.

Sources: NVD GitHub Advisory CISA KEV ATLAS

What is the risk?

Medium severity per CVSS 3.1 (4.3): network-exploitable with low attack complexity and no user interaction, but requiring low privileges (an existing authenticated account) and yielding only limited integrity impact (I:L) with no confidentiality (C:N) or availability (A:N) loss. There is no evidence of active exploitation (not in CISA KEV, no EPSS score available), no public PoC, and no Nuclei scanner coverage, so real-world exploitation likelihood is currently low. The realistic risk is data-integrity contamination in multi-tenant deployments rather than a breach — but because it undermines trust in aggregated statistics, it can indirectly mislead operational or compliance decisions built on that data.

How does the attack unfold?

Initial Access

Attacker authenticates with a valid low-privilege account in their own workspace on a multi-tenant PraisonAI deployment.

AML.T0012

Exploitation

Attacker submits an issue create/update request scoped to their workspace's URL but sets project_id to a project belonging to a different workspace, which the server fails to validate.

AML.T0049

Impact

The forged issue is linked to the victim workspace's project, polluting its project statistics aggregation and corrupting data integrity relied upon by that tenant.

Initial Access

Attacker authenticates with a valid low-privilege account in their own workspace on a multi-tenant PraisonAI deployment.

AML.T0012

Exploitation

Attacker submits an issue create/update request scoped to their workspace's URL but sets project_id to a project belonging to a different workspace, which the server fails to validate.

AML.T0049

Impact

The forged issue is linked to the victim workspace's project, polluting its project statistics aggregation and corrupting data integrity relied upon by that tenant.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	—	No patch
1 dependents 66% patched ~14d to patch Full package profile →

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1

4.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 5% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I Low

A None

What should I do?

1 step

Upgrade to PraisonAI 0.1.7 or later, where project_id is validated against the URL workspace. Until patched, add a workspace-membership check at the API/middleware layer for all issue create and update endpoints, rejecting requests where the request-body project_id does not belong to the authenticated user's workspace. Audit existing issue records and project statistics for cross-tenant references (project_id/workspace_id mismatches) to detect prior pollution and recompute affected aggregates. Add logging/alerting on authorization checks for issue endpoints so future cross-tenant attempts are visible, and review RBAC/tenant-scoping patterns across other PraisonAI API endpoints that accept object IDs in request bodies for the same class of IDOR.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Agent API AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6 - Data for AI systems

NIST AI RMF

MANAGE 1.3 - Manage AI risks from third parties and system components

Frequently Asked Questions

What is CVE-2026-58653?

PraisonAI before version 0.1.7 fails to check that the project_id supplied in issue create/update API calls actually belongs to the workspace referenced in the URL, letting an authenticated low-privilege user write issues into projects owned by other tenants. This is a textbook broken-object-level-authorization (IDOR) flaw, rated medium (CVSS 4.3) precisely because the confirmed impact is limited to integrity — corrupted project statistics aggregation across tenant boundaries — with no confidentiality or availability loss and no privilege escalation to system control. There is no EPSS score, it is not in CISA KEV, and no public exploit code or Nuclei template exists, so this looks like a disclosed-but-unweaponized bug rather than an active threat; downstream dependent counts are unknown, so blast radius across the ecosystem can't be quantified. If you run PraisonAI as a multi-tenant service (agent workspaces, project/issue tracking for tenants), upgrade to 0.1.7+ now, and in the meantime audit issue records for project_id values that don't match their owning workspace and flag any statistics anomalies for review.

Is CVE-2026-58653 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-58653, increasing the risk of exploitation.

How to fix CVE-2026-58653?

Upgrade to PraisonAI 0.1.7 or later, where project_id is validated against the URL workspace. Until patched, add a workspace-membership check at the API/middleware layer for all issue create and update endpoints, rejecting requests where the request-body project_id does not belong to the authenticated user's workspace. Audit existing issue records and project statistics for cross-tenant references (project_id/workspace_id mismatches) to detect prior pollution and recompute affected aggregates. Add logging/alerting on authorization checks for issue endpoints so future cross-tenant attempts are visible, and review RBAC/tenant-scoping patterns across other PraisonAI API endpoints that accept object IDs in request bodies for the same class of IDOR.

What systems are affected by CVE-2026-58653?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant SaaS platforms.

What is the CVSS score for CVE-2026-58653?

CVE-2026-58653 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.16%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-tenant SaaS platforms

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6

NIST AI RMF: MANAGE 1.3

What are the technical details?

Original Advisory

PraisonAI before 0.1.7 fails to validate that project_id in issue create and update request bodies belongs to the URL workspace. An attacker can create issues referencing projects from other workspaces, causing cross-tenant data pollution in project statistics aggregation without workspace constraints.

Exploitation Scenario

An attacker holds a valid low-privilege account in Workspace A of a multi-tenant PraisonAI deployment. They call the issue create/update API scoped to Workspace A's URL but supply a project_id belonging to Workspace B, a different tenant. Because the server only checks that the caller is authenticated — not that the project_id actually belongs to the URL's workspace — the issue is accepted and linked to Workspace B's project. Repeated or automated submissions let the attacker pollute Workspace B's project statistics aggregation with fabricated issues, degrading the integrity of metrics Workspace B's team or leadership rely on, without ever needing access to Workspace B's own credentials.

Weaknesses (CWE)

CWE-639 Authorization Bypass Through User-Controlled Key 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.