CVE-2026-57125: PraisonAI Jobs API Lets Attackers Bypass Command-Execution Approval

Overview

A critical vulnerability in PraisonAI, an open-source multi-agent orchestration framework for building LLM-based agent teams, allows a completely unauthenticated remote attacker to force arbitrary operating-system command execution. Tracked as CVE-2026-57125 and rated 9.8 (Critical) on CVSS 3.1, the flaw lives in the Jobs API's POST /api/v1/runs endpoint, which accepts an attacker-controlled agent_yaml job specification with no credentials whatsoever.

PraisonAI ships a @require_approval safety decorator meant to pause execution and require explicit human sign-off before an agent is allowed to run high-risk tools such as execute_command. CVE-2026-57125 shows that gate can be forged: the submitted agent_yaml may carry a top-level approve field, and the job parser honors that field as a pre-existing approval record before @require_approval ever gets a chance to enforce a real check. An attacker who simply POSTs a crafted job — no token, no session, no operator involvement — can mark execute_command as already approved and have PraisonAI run their commands for them.

Technical Details

How It Works

The Jobs API's POST /api/v1/runs endpoint accepts a JSON payload containing agent_yaml — a YAML document describing the agents, tasks, and tools PraisonAI should run for that job — and executes it. The endpoint does not require an API token, session cookie, or any other credential, so any network-reachable caller can submit a job.

Separately, PraisonAI gates dangerous tools like execute_command behind a @require_approval decorator, designed to pause a run and wait for a human operator to explicitly approve the action before it executes. The vulnerability is a chain, not a single bug: the YAML parsing path in the jobs pipeline (reported against src/praisonai/praisonai/jobs/router.py, around the code handling the POST /api/v1/runs route) also honors a top-level approve field embedded in the very same attacker-supplied agent_yaml. Because that field is trusted as evidence that a tool has already cleared approval, it satisfies @require_approval's check before the decorator's own runtime logic runs — the approval gate ends up validating a claim made by the same untrusted payload it exists to police.

The practical effect: an attacker crafts a job spec that (1) defines an agent with access to execute_command, (2) sets approve so that tool is marked pre-approved, and (3) instructs the agent to run an arbitrary shell command. Submitted to the unauthenticated /api/v1/runs endpoint, that job runs end to end with no human ever seeing an approval prompt. Guidance accompanying the fix suggests the underlying flaw was in the YAML parser (yaml_parser.py) accepting the approve field at all — the recommended remediation is to strip that field's handling entirely or restrict it to a strict allow-list of non-dangerous tools, which is what versions 4.6.59 / 1.6.59 implement alongside closing the authentication gap on the endpoint itself.

Impact Assessment

Who Is At Risk

• Any organization running a PraisonAI Jobs API server before 4.6.59 (or praisonaiagents before 1.6.59) that is reachable over a network without an authentication layer in front of it
• Teams that deployed PraisonAI as an internal automation or agent-orchestration backend and assumed the built-in @require_approval gate was itself a sufficient access control
• Environments where the Jobs API is exposed to a shared internal network, a CI/CD runner network, or — worst case — the public internet
• Any downstream system reachable from the host running PraisonAI: cloud credentials, internal APIs, secrets in environment variables, and adjacent infrastructure are all exposed once command execution is achieved

Potential Attack Chains

1. Unauthenticated Job Submission — An attacker sends a POST /api/v1/runs request with a crafted agent_yaml defining an agent that has access to execute_command. No credentials are needed.
2. Approval Spoofing — The same YAML payload sets a top-level approve field, which the jobs pipeline treats as a valid pre-approval record for execute_command, satisfying @require_approval before any human is involved.
3. Arbitrary Command Execution — The agent runs the attacker-specified OS command on the host process running PraisonAI, with whatever privileges that process holds.
4. Post-Exploitation — Command execution is used to harvest local credentials and cloud/API keys, pivot to adjacent services, install persistence, or exfiltrate data reachable from the compromised host.

Mitigation

Immediate Actions

• Upgrade immediately to praisonai 4.6.59 (or later) and praisonaiagents 1.6.59 (or later), which close both the authentication gap on the Jobs API and the approve field spoofing path.
• Do not expose /api/v1/runs to an untrusted network. Until patched, place the Jobs API behind a reverse proxy or API gateway that enforces its own authentication — PraisonAI's own approval mechanism is not a substitute for access control.
• Audit access logs for POST /api/v1/runs requests from unexpected sources, especially any request whose agent_yaml body references execute_command or another sensitive tool.
• Review recent job history for any run where a tool gated by @require_approval executed without a corresponding, legitimate operator approval event.

Detection Opportunities

• Alert on POST /api/v1/runs requests that lack expected authentication headers or originate from outside known-good source ranges.
• Flag any submitted agent_yaml containing a top-level approve field, particularly one that pre-approves execute_command or other high-risk tools.
• Monitor process trees on hosts running the PraisonAI Jobs API for shell or command execution that does not correlate with a legitimate, human-approved job.
• Watch for anomalous outbound connections or credential access originating from the PraisonAI service process shortly after an unexplained job submission.

Defence-in-Depth

• Treat in-application "approval" or "human-in-the-loop" gates as a workflow convenience, not a security boundary — enforce hard authentication and authorization (API keys, mTLS, RBAC) in front of any endpoint that can trigger tool execution.
• Never let a payload attest to its own approval status. Approval state for dangerous actions should be recorded and checked server-side, independent of anything the caller submits.
• Sandbox or isolate agent tool execution (containers, restricted service accounts, no unnecessary outbound network access) so that a single bypass doesn't translate directly into full host or environment compromise.
• Periodically audit AI-agent frameworks and automation platforms for other instances of the same pattern — fields like approve, approved, or pre_authorized supplied by the same untrusted request they are meant to gate.

Background

PraisonAI is an open-source framework for building teams of LLM-driven agents that can plan tasks, call tools, and — for higher-risk actions like running shell commands — pause for human approval. That approval gate is the framework's core safety promise for anything capable of touching the underlying host, which is precisely what CVE-2026-57125 defeats.

CVE-2026-57125 was published 2026-09-14 as part of a cluster of PraisonAI security disclosures fixed together in the 4.6.59 / 1.6.59 release, reflecting a broader pattern of the framework's early API surface trusting inputs it should not have. It was disclosed alongside CVE-2026-57123, a separate, unauthenticated exposure of PraisonAI's MCP server (ToolsMCPServer/SSE) in the same release — a different bug with a different root cause, but a reminder that the same release cycle closed multiple "the automation surface was implicitly trusted" gaps at once. Organizations running either component should treat the full 4.6.59 / 1.6.59 upgrade as a single, non-optional patch cycle rather than cherry-picking fixes.

References

• NVD — CVE-2026-57125
• GitHub Security Advisory — GHSA-4869-x4pr-q22x
• OSV.dev — GHSA-4869-x4pr-q22x
• PraisonAI Release v4.6.59
• NVD — CVE-2026-57123 (related PraisonAI MCP server exposure)