CVE-2026-61441: IDOR lets members delete owner

CISO Take

A workspace member in PraisonAI Platform can delete dependency links between issues that an owner or admin explicitly created, simply by aiming the delete request at their own issue endpoint instead of the owner's — the server checks permissions against whichever side of the dependency edge the caller picks, not both. For CISOs running PraisonAI to orchestrate multi-agent or task workflows, this means a low-privileged internal user can quietly strip out ordering and gating relationships between tasks, potentially bypassing approval gates or breaking execution sequencing, without needing elevated access, a public exploit, or user interaction — it's a 403-bypass any authenticated member can trigger by hand once they know which issue they own on the same edge. There's no evidence of active exploitation (not in CISA KEV, no EPSS score, no public PoC or Nuclei template), and confidentiality/availability are untouched (CVSS C:N/A:N), but integrity impact is rated high because the attacker fully controls which dependencies survive. Patch to praisonai-platform 0.1.9 or later, and in the interim audit dependency-deletion logs for member accounts removing edges tied to owner-created issues they otherwise can't touch.

Sources: NVD GitHub Advisory vulncheck.com ATLAS

What is the risk?

Medium overall risk (CVSS 6.5). The bug is a classic broken object-level authorization (IDOR/CWE-862): the DELETE dependency route accepts either endpoint of a dependency edge but only validates permission against the caller-chosen side, so a member blocked via the owner's issue can achieve the same delete via their own issue. Attack vector is network, complexity low, and it requires only low privileges (an existing workspace member account) with no user interaction — trivially repeatable and scriptable once discovered. Impact is confined to integrity of dependency relationships (no data exfiltration, no availability loss, no code execution), which caps severity at medium rather than critical. No public exploit code, Nuclei template, KEV listing, or EPSS score exists, so opportunistic mass exploitation is unlikely; the realistic threat is a malicious or compromised internal/insider account within a multi-tenant PraisonAI deployment.

How does the attack unfold?

Valid low-privileged account

Adversary obtains or already holds a PraisonAI Platform workspace member account with restricted (non-owner) permissions.

AML.T0012

Identify dependency edge

Adversary locates an owner-created issue dependency and confirms the same edge is also addressable via a member-owned issue endpoint.

Endpoint substitution

Adversary sends the DELETE dependency request against the member-owned issue endpoint instead of the owner-owned one, so the permission check validates against the wrong issue's owner and succeeds.

Unauthorized dependency removal

The owner-created dependency relationship is deleted without authorization, disrupting workflow ordering or removing an approval gate the owner had set on an agent task.

Valid low-privileged account

Adversary obtains or already holds a PraisonAI Platform workspace member account with restricted (non-owner) permissions.

AML.T0012

Identify dependency edge

Adversary locates an owner-created issue dependency and confirms the same edge is also addressable via a member-owned issue endpoint.

Endpoint substitution

Adversary sends the DELETE dependency request against the member-owned issue endpoint instead of the owner-owned one, so the permission check validates against the wrong issue's owner and succeeds.

Unauthorized dependency removal

The owner-created dependency relationship is deleted without authorization, disrupting workflow ordering or removing an approval gate the owner had set on an agent task.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 34% 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 High

A None

What should I do?

1 step

Upgrade praisonai-platform to 0.1.9 or later, where the fix should validate delete permission against both endpoints of the dependency edge (or against the edge's true owner) rather than the caller-selected issue. Until patched, restrict issue-dependency deletion to owner/admin roles at the application or reverse-proxy layer if feasible, and review workspace role assignments to limit members who can create issues that share dependency edges with owner-created issues. Detect exploitation by auditing dependency-deletion events (commit reference: github.com/MervinPraison/PraisonAI commit 846568c) for cases where the acting user lacks delete rights on one endpoint of the edge but successfully deleted via the other; cross-reference the GHSA-mxmx-rh57-jx58 advisory for the exact patched diff.

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 Framework AML.T0012 - Valid Accounts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.2.6 - AI system access control

NIST AI RMF

MANAGE 1.3 - Responses to identified AI risks are documented and monitored regularly

Frequently Asked Questions

What is CVE-2026-61441?

A workspace member in PraisonAI Platform can delete dependency links between issues that an owner or admin explicitly created, simply by aiming the delete request at their own issue endpoint instead of the owner's — the server checks permissions against whichever side of the dependency edge the caller picks, not both. For CISOs running PraisonAI to orchestrate multi-agent or task workflows, this means a low-privileged internal user can quietly strip out ordering and gating relationships between tasks, potentially bypassing approval gates or breaking execution sequencing, without needing elevated access, a public exploit, or user interaction — it's a 403-bypass any authenticated member can trigger by hand once they know which issue they own on the same edge. There's no evidence of active exploitation (not in CISA KEV, no EPSS score, no public PoC or Nuclei template), and confidentiality/availability are untouched (CVSS C:N/A:N), but integrity impact is rated high because the attacker fully controls which dependencies survive. Patch to praisonai-platform 0.1.9 or later, and in the interim audit dependency-deletion logs for member accounts removing edges tied to owner-created issues they otherwise can't touch.

Is CVE-2026-61441 actively exploited?

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

How to fix CVE-2026-61441?

Upgrade praisonai-platform to 0.1.9 or later, where the fix should validate delete permission against both endpoints of the dependency edge (or against the edge's true owner) rather than the caller-selected issue. Until patched, restrict issue-dependency deletion to owner/admin roles at the application or reverse-proxy layer if feasible, and review workspace role assignments to limit members who can create issues that share dependency edges with owner-created issues. Detect exploitation by auditing dependency-deletion events (commit reference: github.com/MervinPraison/PraisonAI commit 846568c) for cases where the acting user lacks delete rights on one endpoint of the edge but successfully deleted via the other; cross-reference the GHSA-mxmx-rh57-jx58 advisory for the exact patched diff.

What systems are affected by CVE-2026-61441?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, task orchestration pipelines, multi-agent workflows.

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

CVE-2026-61441 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.41%.

What is the AI security impact?

Affected AI Architectures

agent frameworkstask orchestration pipelinesmulti-agent workflows

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 1.3

What are the technical details?

Original Advisory

PraisonAI Platform (praisonai-platform) before 0.1.9 improperly authorizes deletion of issue dependencies. The DELETE dependency route accepts either endpoint of a dependency edge and checks delete permission only against the caller-selected URL issue. A workspace member who cannot delete a dependency through an owner-created issue endpoint (which returns 403) can delete the same dependency edge by targeting a related member-owned issue endpoint, because permission is validated against the member-owned issue's owner. This allows members to bypass owner/admin authorization and remove owner-created issue dependencies.

Exploitation Scenario

A workspace member with legitimate but restricted access attempts to delete a dependency edge via the owner-created issue's endpoint and receives a 403 as expected. The member then inspects the dependency relationship, identifies that the same edge is also reachable through a member-owned issue on the other end, and re-sends the DELETE request targeting that member-owned issue ID instead. Because the platform validates permission only against the caller-selected issue's owner, the request succeeds and the owner-created dependency is removed — silently altering task/workflow ordering, potentially removing an approval gate an admin had placed in front of an automated agent action, with no elevated privileges, exploit tooling, or victim interaction required.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-862 Missing Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.