PraisonAI: 19 Critical and High-Severity CVEs Disclosed in Single-Day Security Dump
A coordinated disclosure of 19 CVEs spanning privilege escalation, IDOR, hardcoded JWT secrets, sandbox escapes, and unauthenticated RCE in PraisonAI's platform and agent tooling.
Key findings
- 19 CVEs disclosed in a single 35-minute window on May 29, 2026
- Workspace authorization collapses: any member can escalate to owner or lock out the real owner
- JWT signing key defaults to hardcoded 'dev-secret-change-me' — token forgery for any user
- A2A example server ships with no auth, binds 0.0.0.0, and exposes eval() to the internet
- Sandbox escape via print.__self__ builtins leak in execute_code subprocess mode
- Deploy --type api emits an unauthenticated Flask server by default
On May 29, 2026, security researchers disclosed a batch of 19 CVEs affecting PraisonAI — an open-source multi-agent orchestration framework — across both its Platform API server and its core Python agent library (praisonai pip package). The vulnerabilities, published within a 35-minute window, range from critical-severity privilege escalation and authentication bypass to high-severity insecure direct object references (IDOR), arbitrary file operations, and sandbox escapes. Together they paint a picture of systemic authorization gaps and insecure defaults across the entire PraisonAI stack.
Workspace Authorization Collapse (Platform API)
The largest cluster of CVEs targets PraisonAI Platform's workspace isolation model. The root cause is a shared FastAPI dependency — require_workspace_member(workspace_id) — that defaults to min_role="member" and is never tightened for privileged routes. This allows any workspace member to escalate their own role.
CVE-2026-47416 (Critical) and CVE-2026-47405 (High) both describe the same core flaw: the PATCH /workspaces/{id}/members/{user_id} endpoint lets any member promote themselves or others to owner. CVE-2026-47409 (High) goes further — the DELETE /workspaces/{workspace_id}/members/{user_id} endpoint allows any member to remove the workspace owner, enabling full workspace takeover and owner lockout.
CVE-2026-47407 (Critical) and CVE-2026-48169 (High) capture the broader cross-workspace IDOR pattern: route handlers look up inner resources (issues, projects, members) by global UUID without verifying they belong to the workspace in the URL path. CVE-2026-47399 (High) generalizes this as a systemic flaw affecting all workspace-scoped REST routes.
Label, Dependency, and Activity IDORs
Several CVEs target specific resource types with the same missing ownership check. CVE-2026-47414 (High) covers five label endpoints — PATCH/DELETE /workspaces/{id}/labels/{label_id}, POST/DELETE /workspaces/{id}/issues/{issue_id}/labels/{label_id}, and GET /workspaces/{id}/issues/{issue_id}/labels — all gated only on workspace membership, not label ownership. CVE-2026-47406 (High) targets dependency endpoints (POST/GET/DELETE /workspaces/{id}/issues/{issue_id}/dependencies), allowing cross-workspace issue linking and deletion. CVE-2026-47408 (High) exposes the activity log endpoint (GET /workspaces/{id}/issues/{issue_id}/activity), which returns activity for any issue ID regardless of workspace.
Critical Authentication and Key Management Failures
CVE-2026-47410 (Critical) reveals that the JWT signing key defaults to the hardcoded literal "dev-secret-change-me" when PLATFORM_JWT_SECRET is unset. A safety check exists but only fires when PLATFORM_ENV != "dev" — and the default value of PLATFORM_ENV is "dev", so the check is silently bypassed. This allows token forgery for any user.
CVE-2026-47393 (Critical) documents that praisonai deploy --type api emits a Flask server with authentication disabled by default, binding to 0.0.0.0. This is a follow-up to the previously disclosed CVE-2026-44338.
CVE-2026-47396 (Critical) describes the call server's agent control API (praisonai.api.agent_invoke), which fails open when CALL_SERVER_TOKEN is unset, exposing unauthenticated agent listing, invocation, and deletion.
Unauthenticated Remote Code Execution and Sandbox Escapes
CVE-2026-47391 (Critical) chains three behaviors in PraisonAI's first-party A2A server example: no auth_token configured, binding to 0.0.0.0, and a calculate(expression) tool implemented via eval(). This gives unauthenticated remote attackers LLM-driven eval() execution.
CVE-2026-47392 (Critical) describes a sandbox escape in execute_code() (subprocess mode) using print.__self__ to leak the real Python builtins module, from which __import__ can be extracted for arbitrary OS command execution.
CVE-2026-47398 (High) is a sibling of CVE-2026-44334: the v4.6.32 chokepoint refactor added PRAISONAI_ALLOW_LOAD but left spec.loader.exec_module in agents_generator.py unguarded, enabling arbitrary code execution.
File Operations and SSRF
CVE-2026-47397 (High) allows arbitrary file write: hidden webpage metadata causes PraisonAI agents to call write_file with workspace=None (always None in production), skipping path validation entirely.
CVE-2026-47394 (High) reports an incomplete fix for CVE-2026-44336: the original advisory named four vulnerable MCP handlers, but the patch missed workflow.show, workflow.validate, and deploy.validate, leaving unauthenticated arbitrary file read open.
CVE-2026-47395 (High) describes the CLI's @url: mention parser, which performs direct urllib.request.urlopen() requests to attacker-supplied URLs, including loopback addresses, leaking internal services into model context.
CVE-2026-47390 (High) covers an SSRF protection bypass in spider_tools URL validation, which can be circumvented using alternate loopback host encodings.
Response and Patch Status
As of the disclosure date, patches were expected across the affected components. Users of PraisonAI Platform should ensure PLATFORM_JWT_SECRET is set to a strong, unique value and that PLATFORM_ENV is configured for production. For the agent library (praisonai pip package), versions <= 4.6.37 are affected by the file write and sandbox escape issues. The A2A example server should never be deployed without authentication. Organizations running praisonai deploy --type api should verify authentication is enabled.
Why This Batch Matters
This disclosure reveals that PraisonAI's rapid development cycle outpaced its authorization and security hardening. The recurring pattern — a shared require_workspace_member dependency that defaults to the weakest role, hardcoded development secrets shipped to production, and example servers that bind to all interfaces without auth — suggests the project needs a security-focused audit of its middleware, defaults, and deployment tooling. Users should treat all PraisonAI instances as potentially compromised until the full patch set is applied.