All posts
Unproven Execution

PraisonAI: Default-Off Auth on Default-On Agent Tools

CVE-2026-44338 leaves PraisonAI's legacy Flask API with auth off by default, letting unauthenticated callers invoke its agents.yaml tool surface

Securityv0 Intelligence Team OWASP: ASI05 sv0 finding: unproven_execution
praisonai llm-agent unproven-execution asi05 cve-2026-44338 flask-api

The Incident

On 2026-05-11 at 13:56 UTC, a GitHub Security Advisory disclosed CVE-2026-44338 (CVSS 7.3), a missing-authentication flaw in PraisonAI — an open-source multi-agent orchestration framework — whose legacy Flask API server (src/praisonai/api_server.py) ships with AUTH_ENABLED = False and AUTH_TOKEN = None as hardcoded defaults. Any caller that can reach the server can enumerate configured agents via /agents and invoke the operator’s agents.yaml workflow through /chat by posting a JSON body with a message key — no token required. In production deployments those workflows typically call LLM providers (Anthropic, Bedrock, OpenAI) and attach code interpreters, shells, and file-I/O tools, so an unauthenticated /chat invocation is a remote handle on whatever capabilities the agent was wired up with. The praisonai Python package versions 2.5.6 through 4.6.33 are affected; the issue is patched in 4.6.34.

At 17:40 UTC the same day — about three hours and forty-four minutes after the advisory landed — Sysdig observed the first targeted scan on its internet-exposed honeypot. The probing client identified itself by the user-agent CVE-Detector/1.0 and pivoted through PraisonAI-specific paths: /praisonai/version.txt, /docs, /api/agents/config, and /api/agents. A separate flaw in the same project, CVE-2026-44340 (CVSS 8.7), was disclosed the same week and is patched in praisonai 4.6.37. MITRE ATT&CK coverage: T1190 Exploit Public-Facing Application, T1059 Command and Scripting Interpreter, T1496 Resource Hijacking.

The Authority Path That Failed

The identity carrying execution authority at the moment of failure is the PraisonAI Flask api_server.py process — a service identity that holds the operator’s LLM provider keys, the configured agents.yaml toolchain (Python interpreter, shell, file I/O), and whatever filesystem and network reach the host grants. The scope it held is the full agent tool-belt plus paid inference capacity. The scope it exercised at failure was identical — except invoked by arbitrary unauthenticated HTTP callers rather than by the operator. Two defaults made that possible: AUTH_ENABLED = False left the network surface open, and agents.yaml attached code-execution tools that the deploying operator never had to explicitly opt in to.

The trust anchor that failed first is the framework default itself. PraisonAI ships an API server that treats both “no authentication” and “shell/Python tool attached” as the out-of-the-box experience, so an operator who follows the documented start-here path gets a code-execution endpoint with no gate in front of it. The gap between held scope (full toolchain + provider keys) and exercised scope (unauthenticated /chat) is exactly the surface a configuration audit could have flagged before the CVE landed: which deployed agent has a Python interpreter or shell tool attached, and which network path can reach it without a credential?

SecurityV0 Perspective

This is a clean unproven_execution (ASI05) finding — the sibling case to Langflow’s CSV Agent + Python REPL, moved one layer down the stack from a UI affordance to a framework default. SV0’s evidence pack would enumerate every PraisonAI deployment in the fleet, identify each one whose agents.yaml attaches a code-execution tool (Python REPL, shell, file I/O, or any user-defined subprocess-style tool), and tie that to the network reachability and current AUTH_ENABLED value for its API server process. The pre-exfiltration question the pack answers is which agents in our fleet have a code-execution tool attached that no human explicitly authorized, and which of those are reachable from a network they shouldn’t be on. The post-exfiltration question is between 2026-05-11 13:56 UTC and the patch deployment timestamp, which unauthenticated HTTP callers invoked /chat against a PraisonAI host, and which LLM provider, cloud, or filesystem calls did the resulting agent runs make on our behalf.

The secondary angle is nhi_compromise (ASI06). The operator’s Anthropic, Bedrock, and OpenAI keys are non-human identities embedded in the host environment, and an unauthenticated /chat call quietly delegates those identities to the attacker for the duration of the workflow. The cost-incurring side effect is downstream of the unproven-execution failure, but for finance and FinOps teams it is the most visible signal: a sudden change in LLM provider spend on a host running an exposed praisonai API is a high-fidelity indicator of post-disclosure exploitation.

What To Do

  • Upgrade praisonai to 4.6.34 or later, then 4.6.37 to also cover CVE-2026-44340. The 4.6.34 release enforces token validation on the legacy Flask API server; 4.6.37 closes a separate symlink-traversal file-write flaw in the same project disclosed the same week. Pin the minimum version in your lockfile and refuse <4.6.37 in CI for any service that imports praisonai.
  • Audit every agents.yaml for an attached code-execution tool. Treat any agent whose tool list includes a Python REPL, shell, subprocess-style executor, or unrestricted file I/O as carrying unproven execution authority unless a named owner explicitly approved that attachment. The audit query is “which agent in our fleet has a shell tool that no human signed off on?” — answer it before the next CVE in this class lands.
  • Block PraisonAI’s legacy API server from any network it should not be on. Put the Flask api_server.py behind an authenticating reverse proxy or a service-mesh policy that requires a workload identity; do not rely on the framework’s own AUTH_ENABLED flag as the only gate. Treat api_server.py listening on 0.0.0.0 without an upstream auth layer as a fleet-wide incident, not a config drift.
  • Hunt for CVE-Detector/1.0 and the Sysdig endpoint signatures in your edge logs. Requests to /praisonai/version.txt, /api/agents/config, /api/agents, or /chat from that user-agent against any host that ever ran PraisonAI between 2026-05-11 13:56 UTC and your patch deployment timestamp should be triaged as exploitation evidence, not noise. Correlate with the host’s LLM-provider egress for the same window.
  • Inventory the NHIs each PraisonAI host can reach. Anthropic / Bedrock / OpenAI keys, cloud SDK credentials, kubeconfigs, and any tool-specific tokens loaded into the agent process are all in scope for rotation if /chat was reachable without auth at any point in the window. Revoke-then-reissue is safer than rotate-in-place for keys that may have been used by an unauthenticated caller mid-window.

Sources

All posts