CVE-2026-40149
Praisonai ≤ 4.5.128
Raw vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:NSummary
CVE-2026-40149 is a high-severity Declaration of Catch for Generic Exception (CWE-396) vulnerability in Praison Praisonai. Its CVSS base score is 7.9 (High).
Operationally, ranked at the 14th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-40149 is a vulnerability in PraisonAI, a multi-agent teams system, affecting versions prior to 4.5.128. The issue lies in the gateway's /api/approval/allow-list endpoint, which permits unauthenticated modification of the tool approval allowlist when no auth_token is configured, which is the default setting. This CWE-396 flaw enables attackers to add dangerous tool names, such as shell_exec or file_write, to the allowlist, causing the ExecApprovalManager to auto-approve future agent invocations of those tools and bypassing the human-in-the-loop safety mechanism. The vulnerability has a CVSS v3.1 base score of 7.9 (AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N).
A local attacker with no privileges required can exploit this low-complexity vulnerability without user interaction. By sending an unauthenticated request to the endpoint, the attacker modifies the allowlist to include high-risk tools, enabling subsequent agent executions to run those tools automatically without human approval. This grants the attacker high integrity impact, such as arbitrary file writes or shell command execution via agents, along with low confidentiality impact in a changed scope.
The GitHub Security Advisory at https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-4wr3-f4p3-5wjh details the fix in PraisonAI version 4.5.128, which addresses the unauthenticated modification issue. Security practitioners should upgrade to 4.5.128 or later and configure an auth_token on the gateway endpoint to mitigate exploitation.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-21168
Vulnerability Data
PraisonAI is a multi-agent teams system. Prior to 4.5.128, the gateway's /api/approval/allow-list endpoint permits unauthenticated modification of the tool approval allowlist when no auth_token is configured (the default). By adding dangerous tool names (e.g., shell_exec, file_write) to the allowlist, an…
more
attacker can cause the ExecApprovalManager to auto-approve all future agent invocations of those tools, bypassing the human-in-the-loop safety mechanism that the approval system is specifically designed to enforce. This vulnerability is fixed in 4.5.128.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V16.5.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including static analysis and code review) directly finds declarations of overly generic catch blocks.
Requiring documented development standards and tools can mandate specific exception-handling rules that prohibit generic catches.
Security engineering principles include explicit requirements for precise, least-privilege exception handling rather than broad catches.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly enforce specific exception handling as part of coding standards, though the control addresses the full development lifecycle beyond this single weakness.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect generic catch blocks, but does not guarantee their removal.
Secure SDLC processes encourage disciplined exception handling, yet the control itself does not mandate specific coding rules.
Secure coding standards explicitly prohibit overly broad exception handlers that mask errors and create exploitable paths.