PraisonAI, a Python multi-agent orchestration framework used to wire LLMs into autonomous coding and workflow agents, has picked up two more critical CVEs: CVE-2026-61445 (CVSS 9.9) and CVE-2026-61447 (CVSS 10.0), both disclosed July 11 and both reachable through nothing more than a crafted prompt. Combined, they let an attacker who can talk to a PraisonAI deployment’s chat interface write files anywhere on the host and run arbitrary shell or Python code as the service user.

What happened

PraisonAI ships an “AICoder” agent component intended to let an LLM write and modify files as part of a coding task. CVE-2026-61445 is a missing-validation bug in how AICoder handles LLM tool calls: neither the file path nor the shell command the model wants to run is checked before execution. A prompt that gets the model to emit a tool call with a path like /etc/cron.d/x or a command string laced with shell metacharacters goes straight through — no allowlist, no canonicalization, no sandbox boundary. The result is arbitrary file write to any location the process can reach, plus arbitrary shell command execution, in installations that run the agent with elevated privileges (a common pattern for coding assistants that need to touch the filesystem freely).

CVE-2026-61447 is worse in scope even though the score only ticks up to a full 10.0: it’s in CodeAgent._execute_python(), the function PraisonAI uses to run Python code that the LLM generates as part of an agentic workflow. There is no AST inspection of the generated code before execution, no import allowlist or denylist, and no sandbox (no restricted exec, no subprocess isolation, no seccomp/gVisor boundary) around the call. Any code the model can be coaxed into producing — via prompt injection from a poisoned document, a malicious tool response, or a directly hostile user — runs with full interpreter privileges. That’s a straight line from “attacker can influence LLM output” to “attacker has a Python REPL on the host,” which for many PraisonAI deployments also means read access to every API key and cloud credential in the process environment.

Both bugs affect PraisonAI releases prior to 4.6.78; the vendor has shipped 4.6.78 with the fixes. Neither disclosure lists an authentication requirement beyond reachability of the chat/agent interface, which for internet-exposed or multi-tenant PraisonAI deployments means the practical barrier to exploitation is “can this attacker get a prompt in front of the model” — a bar that includes classic indirect prompt injection via retrieved documents, tool outputs, or webhook payloads, not just a direct chat message.

Why this keeps happening to PraisonAI specifically

This is not PraisonAI’s first critical RCE and it won’t obviously be its last — the project has accumulated a long tail of GHSA advisories this year covering MCP command injection, path-traversal-to-RCE via .pth file planting, an unauthenticated legacy Flask API server shipped with auth disabled by default, SSRF filter bypasses, and untrusted remote template execution. The pattern across nearly all of them is the same: user- or LLM-controlled input reaching a subprocess, exec, or filesystem-write sink with no intermediate validation layer. AICoder and CodeAgent._execute_python() are just the latest sinks to get the same treatment. Any team running PraisonAI should treat the whole “code execution” surface of the framework as untrusted by default rather than patching CVE-by-CVE.

Impact

Any organization running a PraisonAI-based agent that is reachable by external users, or that ingests external content (web pages, emails, tickets, documents) into its context, is exposed. Because AICoder and the Python code-execution path are core to what makes these agents useful — writing files, running code — there’s no meaningful “safe” configuration short of patching; disabling the affected components removes most of the product’s value. Environment variable exfiltration is the most immediate risk: cloud credentials, database connection strings, and third-party API keys sitting in the process environment are trivially readable once arbitrary Python execution is achieved.

Mitigation

  • Upgrade to PraisonAI 4.6.78 or later immediately; both CVEs are fixed in that release.
  • Until patched, treat any PraisonAI instance with AICoder or CodeAgent enabled as equivalent to an open shell — isolate it in a container or VM with no access to production credentials, and strip cloud IAM roles or long-lived secrets from its environment.
  • Run PraisonAI agents under a dedicated low-privilege OS user, never root, and enforce filesystem write restrictions (read-only root filesystem, explicit writable mount points) at the container/OS level rather than relying on the application.
  • Audit any external-content ingestion paths (RAG retrieval, tool outputs, webhook-fed prompts) for indirect prompt injection exposure — direct-chat-only threat modeling undercounts the actual attack surface here.
  • Monitor for anomalous child processes or unexpected file writes originating from the PraisonAI process as a compensating control while patching rolls out.

Advisory details: CVE-2026-61445, CVE-2026-61447. Prior PraisonAI advisories: GitHub Security Advisories, MervinPraison/PraisonAI.