Kai Ole Hartwig
6 min read
Critical

PraisonAI CVE-2026-57125, -57124 and -57131: Unauthenticated Jobs and MCP Endpoints Allow Remote Code Execution in AI Agent Framework

PraisonAI, an open-source Python framework for multi-agent AI systems, carries several critical vulnerabilities in its default endpoints. CVE-2026-57125 (CVSS 9.8) uses the unauthenticated Jobs API (POST /api/v1/runs) to bypass the approval check for critical tools. CVE-2026-57124 (CVSS 9.8) allows OS command injection via the MCP-connect endpoint (POST /api/mcp/connect), because the interface binds to 0.0.0.0 by default. CVE-2026-57131 (CVSS 9.8) describes a complete absence of authentication on the Jobs router itself. All three are fixed in PraisonAI 4.6.58 or 4.6.59, and praisonaiagents 1.6.59.

TL;DR — 90 seconds

PraisonAI ships several HTTP endpoints without authentication in its default configuration. Three of them are now documented as separate CVEs, each rated CVSS 9.8. The Jobs API accepts a field that lets the caller set the approval check for critical tools like execute_command themselves. The MCP-connect endpoint passes command and arguments to a local process without checking them. The Jobs router does not check who is making the request at all. All three need only network reachability, no credentials. Patch: PraisonAI 4.6.58 (for CVE-2026-57131) and 4.6.59 (for CVE-2026-57125 and CVE-2026-57124), plus praisonaiagents 1.6.59.

What is the problem?

PraisonAI starts several HTTP endpoints without authentication by default: the Jobs API for controlling agent runs, an MCP-connect endpoint for wiring up external tool servers, and the AgentOS interface. All three bind to 0.0.0.0 by default and are reachable across the network as soon as the host itself is reachable.

For CVE-2026-57125, the Jobs API (function praisonai.jobs.server.create_app, router praisonai.jobs.router.create_router) accepts an agent_yaml field in which the caller sets an approve flag. This flag marks critical tools such as execute_command as already approved before the actual approval check runs. For CVE-2026-57124, the endpoint POST /api/mcp/connect passes the parameters command and args from an incoming request straight to StdioMCPClient, so arbitrary OS commands run even when the MCP handshake fails afterward. CVE-2026-57131 lacks any authentication or authorization check on the Jobs router.

Who is affected?

Installations running default configuration where the affected services are reachable on the network:

CVEEndpointAffectedFixCVSS
CVE-2026-57125POST /api/v1/runsPraisonAI < 4.6.59, praisonaiagents < 1.6.594.6.59 / 1.6.599.8
CVE-2026-57124POST /api/mcp/connectPraisonAI < 4.6.594.6.599.8
CVE-2026-57131Jobs router (/api/v1/runs)PraisonAI < 4.6.584.6.589.8

What matters is whether the relevant ports are reachable from outside or from an internal network. Purely local installations on localhost without port forwarding are not exposed to remote exploitation.

Impact

All three cases require only network reachability of the relevant port. No credentials, no user interaction. An attacker can submit their own agent configurations, view and cancel running jobs, access result streams, and, for CVE-2026-57125 and CVE-2026-57124, run arbitrary shell commands on the host with the privileges of the PraisonAI process.

Agent frameworks commonly run with connected credentials for other systems: databases, cloud APIs, internal tools. Compromise therefore typically reaches beyond the PraisonAI host into the infrastructure behind it.

Mitigation / Immediate actions

Update to PraisonAI 4.6.59 and praisonaiagents 1.6.59. That closes CVE-2026-57125 and CVE-2026-57124 together, as well as CVE-2026-57131, which is already fixed from 4.6.58.

Afterward, verify that the Jobs API, the MCP-connect endpoint, and the AgentOS interface actually require authentication. Bind these services to 127.0.0.1 or an internal network segment if no external access is needed, instead of leaving them on 0.0.0.0. Restrict any remaining network access through a reverse proxy with its own authentication if outside access is genuinely required.

Detection / Verification

Check access logs for POST requests against /api/v1/runs and /api/mcp/connect from unknown or external IP addresses. Unusual agent_yaml or command/args payloads containing shell metacharacters (;, |, &&, $()) in these requests are a strong indicator of exploitation attempts.

Also review which child processes have appeared under the PraisonAI service account in recent weeks. Unexpected child processes of python or the PraisonAI worker that do not stem from a known, self-triggered agent run point to exploitation that has already occurred.

Operator recommendation

Act today if: your PraisonAI installation runs default configuration and is reachable on the network or the internet. Patch and restrict network access today.

Monitoring is enough if: PraisonAI runs strictly on localhost and none of the three endpoints are reachable from outside. An update is still recommended once a maintenance window comes up.

Frequently asked questions about the PraisonAI CVE cluster

Conclusion

The PraisonAI case shows a recurring pattern in young agent frameworks. Convenient automation endpoints ship without authentication because local development came first. As soon as a host is reachable on the network, that convenience becomes an unauthenticated command line for anyone who knows the IP address.

Sources

I review your AI agent stacks for open default endpoints, harden network binding and authentication, and support the patch rollout for PraisonAI and adjacent agent frameworks.

Endpoint audits for Jobs APIs, MCP servers and agent interfaces, hardening of network binding and access control, log review for exploitation traces.

Ongoing platform operations, not paper advice: I review, patch, and harden your infrastructure continuously.

About the author