CVE-2026-61440: PraisonAI: broken authz lets members hijack labels

MEDIUM PoC AVAILABLE CISA: TRACK*
Published July 15, 2026
CISO Take

PraisonAI Platform before 0.1.9 fails to check permissions on its label and issue-label endpoints, letting any low-privileged workspace member rename, recolor, or delete shared labels and add or remove labels on issues created by workspace owners. There is no data exfiltration or downtime risk here — CVSS 6.5 with C:N/A:N/I:H reflects a pure integrity issue — but a single hostile or compromised low-priv account (only PR:L, AC:L, no user interaction) can silently corrupt the shared label taxonomy that a whole workspace relies on to triage and track issues. There is no evidence of a public exploit, scanner template, or CISA KEV listing, and only one downstream dependent is tracked, so this is not an urgent, actively-exploited threat — treat it as a routine patch. Upgrade to PraisonAI Platform 0.1.9 or later (fixed in commit 846568c) and, in the interim, review workspace membership lists and audit logs for unexpected label renames or issue-label changes from non-owner accounts.

Sources: NVD GitHub Advisory VulnCheck

What is the risk?

Medium risk. The flaw requires only low-level authenticated access (a standard workspace member role) and no user interaction, and the attack path is a simple direct API call (PATCH/POST/DELETE) against endpoints missing a proper authorization check (CWE-862, missing authorization) — making it trivial to exploit for anyone already inside the workspace. The impact is scoped to integrity of collaboration metadata (labels and issue-label associations); there is no confidentiality or availability impact, no public PoC, no Nuclei template, and it is not in CISA KEV or listed with an EPSS score, so opportunistic mass exploitation is unlikely. The realistic threat model is an insider, a disgruntled contractor, or an attacker who has already obtained low-privilege credentials via phishing or credential stuffing and wants to disrupt or manipulate a team's workflow tracking.

How does the attack unfold?

Initial Access
Attacker holds or obtains a low-privilege workspace member account in a self-hosted or multi-tenant PraisonAI Platform deployment.
Exploitation
Attacker sends direct PATCH/POST/DELETE requests to the label and issue-label endpoints, which lack proper authorization checks (CWE-862), bypassing the intended owner/admin-only restriction.
Impact
Shared label taxonomy is renamed, recolored, or issue-label associations on owner-created issues are altered, corrupting workspace-wide issue tracking integrity and potentially hiding or mislabeling security-relevant issues.

What systems are affected?

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

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1
6.5 / 10
EPSS
0.4%
chance of exploitation in 30 days
Higher than 30% of all CVEs
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 AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C None
I High
A None

What should I do?

1 step
  1. Upgrade PraisonAI Platform to version 0.1.9 or later, which fixes the authorization checks per commit 846568c7a5d8ce9e71e56e4c213f027c04909753. Until patched, restrict workspace membership to trusted users only and avoid granting member-level access to untrusted or external collaborators. Monitor audit/activity logs for label rename, recolor, or issue-label mutation events originating from non-owner/non-admin accounts, and treat unexpected label taxonomy changes as a signal worth investigating. Where possible, put a reverse proxy or API gateway rule in front of the label/issue-label PATCH, POST, and DELETE endpoints to log and alert on calls from low-privilege roles.

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

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.3 - Access control for AI system components
OWASP LLM Top 10
LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-61440?

PraisonAI Platform before 0.1.9 fails to check permissions on its label and issue-label endpoints, letting any low-privileged workspace member rename, recolor, or delete shared labels and add or remove labels on issues created by workspace owners. There is no data exfiltration or downtime risk here — CVSS 6.5 with C:N/A:N/I:H reflects a pure integrity issue — but a single hostile or compromised low-priv account (only PR:L, AC:L, no user interaction) can silently corrupt the shared label taxonomy that a whole workspace relies on to triage and track issues. There is no evidence of a public exploit, scanner template, or CISA KEV listing, and only one downstream dependent is tracked, so this is not an urgent, actively-exploited threat — treat it as a routine patch. Upgrade to PraisonAI Platform 0.1.9 or later (fixed in commit 846568c) and, in the interim, review workspace membership lists and audit logs for unexpected label renames or issue-label changes from non-owner accounts.

Is CVE-2026-61440 actively exploited?

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

How to fix CVE-2026-61440?

Upgrade PraisonAI Platform to version 0.1.9 or later, which fixes the authorization checks per commit 846568c7a5d8ce9e71e56e4c213f027c04909753. Until patched, restrict workspace membership to trusted users only and avoid granting member-level access to untrusted or external collaborators. Monitor audit/activity logs for label rename, recolor, or issue-label mutation events originating from non-owner/non-admin accounts, and treat unexpected label taxonomy changes as a signal worth investigating. Where possible, put a reverse proxy or API gateway rule in front of the label/issue-label PATCH, POST, and DELETE endpoints to log and alert on calls from low-privilege roles.

What systems are affected by CVE-2026-61440?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks.

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

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

What is the AI security impact?

Affected AI Architectures

agent frameworks

Compliance Controls Affected

ISO 42001: A.6.2.3
OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

PraisonAI Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.

Exploitation Scenario

An attacker obtains or already holds a low-privilege 'member' account in a target PraisonAI workspace (e.g., via an open signup flow, a phished invite, or a former-employee account that was never revoked). Instead of using the UI, they call the label PATCH endpoint directly to rename and recolor labels the whole workspace relies on for triage (e.g., turning 'security-critical' into something innocuous), and use the issue-label POST/DELETE endpoints to strip that label from an owner-created issue describing a real vulnerability, effectively hiding it from label-based dashboards and alerting. No exploit tooling is needed beyond a script issuing authenticated HTTP requests to the exposed endpoints.

Weaknesses (CWE)

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.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Timeline

Published
July 15, 2026
Last Modified
July 18, 2026
First Seen
July 15, 2026

Related Vulnerabilities