CVE-2026-61442: workspace members bypass owner authz

CISO Take

PraisonAI Platform fails to enforce owner/admin checks on its PATCH routes for projects, issues, and agents, requiring only a low-privileged workspace-member role; because the delete endpoint trusts the record's lead_id field rather than re-validating the caller's role, any workspace member can reassign themselves as project lead via PATCH and then delete an owner-created project outright. This is a classic broken-object-level-authorization flaw (CWE-862) rather than a novel AI attack, but the blast radius sits squarely inside an AI agent orchestration platform, so a compromised or malicious low-privilege account can destroy production agent configurations, project state, and issue history with a network-only, no-user-interaction call (CVSS 7.1, AV:N/AC:L/PR:L/UI:N). There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this looks opportunistic rather than under active exploitation today — but the fix is trivial to reverse-engineer from the public GitHub commit and GHSA advisory, so exploitation is only a matter of someone reading the diff. Upgrade to praisonai-platform 0.1.9 or later immediately, and in the interim audit recent lead_id reassignments and project/agent deletions for any workspace member acting outside their normal role.

Sources: NVD GitHub Advisory ATLAS vulncheck.com

What is the risk?

High severity per CVSS (7.1) driven by integrity (I:H) and partial availability (A:L) impact with no confidentiality loss (C:N). Exploitability is high in practical terms: attack vector is network, complexity is low, and the only prerequisite is an authenticated low-privilege 'workspace-member' account — no admin/owner rights or social engineering required, and no user interaction. The two-step chain (PATCH to reassign lead_id, then DELETE that now passes the flawed owner check) is trivial to script once discovered. Mitigating factors: no CISA KEV listing, no EPSS score published, no public exploit code or Nuclei scanner template observed, and the flaw requires the attacker to already hold a valid low-privilege account inside a specific tenant/workspace rather than being exploitable pre-auth from the open internet.

How does the attack unfold?

Initial Access

Attacker obtains or already holds a valid low-privilege 'workspace-member' account on a PraisonAI Platform deployment.

AML.T0012

Authorization Bypass

Attacker sends a PATCH request to the project endpoint, reassigning lead_id to their own user ID since PATCH only checks for workspace-member role, not owner/admin.

Configuration Tampering

Now recorded as project lead, the attacker satisfies the (flawed) ownership check used by other mutating endpoints on the project, its issues, and its agents.

AML.T0081

Impact

Attacker issues a DELETE request that trusts the tampered lead_id, permanently destroying the owner-created project along with its associated agents and issue history.

Initial Access

Attacker obtains or already holds a valid low-privilege 'workspace-member' account on a PraisonAI Platform deployment.

AML.T0012

Authorization Bypass

Attacker sends a PATCH request to the project endpoint, reassigning lead_id to their own user ID since PATCH only checks for workspace-member role, not owner/admin.

Configuration Tampering

Now recorded as project lead, the attacker satisfies the (flawed) ownership check used by other mutating endpoints on the project, its issues, and its agents.

AML.T0081

Impact

Attacker issues a DELETE request that trusts the tampered lead_id, permanently destroying the owner-created project along with its associated agents and issue history.

How severe is it?

CVSS 3.1

7.1 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I High

A Low

What should I do?

1 step

Upgrade praisonai-platform to version 0.1.9 or later immediately. Until patched, restrict or monitor the workspace-member role's PATCH access to projects/issues/agents, and specifically alert on any lead_id field change followed shortly by a delete request on the same resource. Review PATCH/DELETE audit logs for the affected period for projects whose lead_id changed to a non-owner user immediately before deletion, and restore any illegitimately deleted projects/agents from backup. Enforce server-side re-validation of the requester's actual role (not a mutable foreign-key field) on every state-changing endpoint as a longer-term architectural fix, and add integration tests asserting that workspace-members cannot escalate via field reassignment.

How is it classified?

Auth Bypass Agent Framework AML.T0012 - Valid Accounts AML.T0081 - Modify AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6 - AI system life cycle controls / operational access management

NIST AI RMF

MANAGE-2.3 - Risks arising from AI system access and use are managed

Frequently Asked Questions

What is CVE-2026-61442?

PraisonAI Platform fails to enforce owner/admin checks on its PATCH routes for projects, issues, and agents, requiring only a low-privileged workspace-member role; because the delete endpoint trusts the record's lead_id field rather than re-validating the caller's role, any workspace member can reassign themselves as project lead via PATCH and then delete an owner-created project outright. This is a classic broken-object-level-authorization flaw (CWE-862) rather than a novel AI attack, but the blast radius sits squarely inside an AI agent orchestration platform, so a compromised or malicious low-privilege account can destroy production agent configurations, project state, and issue history with a network-only, no-user-interaction call (CVSS 7.1, AV:N/AC:L/PR:L/UI:N). There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this looks opportunistic rather than under active exploitation today — but the fix is trivial to reverse-engineer from the public GitHub commit and GHSA advisory, so exploitation is only a matter of someone reading the diff. Upgrade to praisonai-platform 0.1.9 or later immediately, and in the interim audit recent lead_id reassignments and project/agent deletions for any workspace member acting outside their normal role.

Is CVE-2026-61442 actively exploited?

No confirmed active exploitation of CVE-2026-61442 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-61442?

Upgrade praisonai-platform to version 0.1.9 or later immediately. Until patched, restrict or monitor the workspace-member role's PATCH access to projects/issues/agents, and specifically alert on any lead_id field change followed shortly by a delete request on the same resource. Review PATCH/DELETE audit logs for the affected period for projects whose lead_id changed to a non-owner user immediately before deletion, and restore any illegitimately deleted projects/agents from backup. Enforce server-side re-validation of the requester's actual role (not a mutable foreign-key field) on every state-changing endpoint as a longer-term architectural fix, and add integration tests asserting that workspace-members cannot escalate via field reassignment.

What systems are affected by CVE-2026-61442?

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

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

CVE-2026-61442 has a CVSS v3.1 base score of 7.1 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent orchestration platformsmulti-tenant SaaS management layers for agents

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0081 Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6

NIST AI RMF: MANAGE-2.3

What are the technical details?

Original Advisory

PraisonAI Platform (praisonai-platform) before 0.1.9 fails to enforce owner/admin authorization on the PATCH routes for projects, issues, and agents, which only require workspace-member role. A workspace member can modify owner-created records; for projects, a member can reassign lead_id to their own user id and then delete the owner-created project, bypassing the delete route's owner/admin permission check.

Exploitation Scenario

An attacker holding a valid but low-privileged 'workspace-member' account on a multi-tenant PraisonAI Platform instance — for example a departing contractor, a shared customer workspace member, or an account compromised via credential stuffing — sends a PATCH request to the projects endpoint setting lead_id to their own user ID. Because the endpoint only checks for workspace-member role rather than owner/admin, the reassignment succeeds. The attacker then issues a DELETE request against that same project; since the delete route's authorization check reads the (now-attacker-controlled) lead_id instead of the true owner/admin role, it succeeds, permanently destroying the owner's project along with its associated agents and issue history and disrupting whatever agentic workflow depended on it.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary

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.