CVE-2026-57131: PraisonAI Authentication Bypass Vulnerability

CVE-2026-57131 Overview

PraisonAI, a multi-agent teams system, exposes its jobs API without authentication or per-job authorization prior to version 4.6.58. The praisonai.jobs.server.create_app function mounts praisonai.jobs.router.create_router under /api/v1/runs with no access controls. Any network client can submit attacker-controlled prompts and agent configurations, enumerate jobs, stream results, and cancel or delete jobs owned by other users. This exposes service credentials and connected tool capabilities to unauthorized agent execution. The flaw is tracked under [CWE-94] (Improper Control of Generation of Code) and is fixed in release 4.6.58.

Critical Impact
Unauthenticated network attackers can execute arbitrary agent workloads, exfiltrate service credentials, and manipulate other users' jobs on any exposed PraisonAI jobs server.

Affected Products

PraisonAI versions prior to 4.6.58
praisonai.jobs.server component (jobs API server)
praisonai.jobs.router component mounted under /api/v1/runs

Discovery Timeline

2026-09-14 - CVE-2026-57131 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-57131

Vulnerability Analysis

The vulnerability originates in the ASGI application factory praisonai.jobs.server.create_app. The factory mounts the router returned by praisonai.jobs.router.create_router under the /api/v1/runs path without registering an authentication middleware or per-resource authorization check. Every route exposed by that router, including job submission, listing, result streaming, cancellation, and deletion, becomes reachable to any client that can connect to the HTTP port.

Because the endpoints accept attacker-controlled prompts and agent configuration, the server will instantiate agents that inherit the deployment's service credentials and tool bindings. Those tools may include cloud API keys, database connectors, and outbound HTTP clients. An attacker therefore gains indirect execution against every backend the agent runtime can reach, mapped to [CWE-94] because untrusted input drives code generation and tool invocation.

Root Cause

The router is registered without dependency-based authentication and without an object-level authorization check keyed to the caller. Job identifiers are treated as sufficient references, so any client that can guess or list a job_id can act on it. There is no separation between control-plane (submit, cancel, delete) and data-plane (stream results) authorization.

Attack Vector

An unauthenticated remote attacker sends HTTP requests directly to the exposed /api/v1/runs endpoints. The attacker submits a crafted agent configuration, receives a job identifier, streams results, and can enumerate and delete jobs belonging to other tenants. No user interaction, credentials, or prior access are required.

python

# Patch excerpt: src/praisonai-agents/praisonaiagents/server/server.py
# Adds bearer-token authorization to the server request path
self._server_thread: Optional[threading.Thread] = None
self._app = None
self._server = None

def _authorise_request(self, request) -> bool:
    """Verify bearer token when auth_token is configured."""
    token = self.config.auth_token
    if not token:
        return True
    auth = request.headers.get("Authorization", "")
    if auth.startswith("Bearer ") and auth[7:] == token:
        return True
    return request.headers.get("X-Auth-Token") == token

def _create_app(self):
    """Create the ASGI application."""

Source: GitHub Commit 2f9677a

Detection Methods for CVE-2026-57131

Indicators of Compromise

Unexpected inbound HTTP requests to /api/v1/runs endpoints from external or non-allowlisted addresses.
Job records containing prompts or agent configurations that do not match approved workflows.
Outbound network calls from the PraisonAI process to hosts not defined in the tool allowlist.
Unexplained DELETE or CANCEL operations against job_id values owned by other users.

Detection Strategies

Inspect PraisonAI access logs for requests to /api/v1/runs* that lack an Authorization or X-Auth-Token header.
Alert on high-volume job creation from a single source IP, which suggests enumeration or abuse.
Correlate agent tool invocations with the credentials they consumed to identify unexpected credential use.

Monitoring Recommendations

Forward PraisonAI application and reverse-proxy logs to a centralized analytics platform for query and retention.
Monitor egress from the PraisonAI host for traffic to cloud metadata services and unapproved SaaS endpoints.
Baseline normal /api/v1/runs request rates and payload sizes, then alert on statistical deviation.

How to Mitigate CVE-2026-57131

Immediate Actions Required

Upgrade PraisonAI to version 4.6.58 or later, which introduces the authorization check on the jobs router.
Rotate any API keys, database credentials, and tokens configured as agent tools on affected deployments.
Restrict network exposure of the jobs API to trusted management networks until the upgrade is verified.

Patch Information

The fix is published in PraisonAI release v4.6.58 and described in GHSA-fq2m-6wqh-x44g. The remediation commit adds an _authorise_request bearer-token check and hardens input handling. See the patch commit 2f9677a for the full diff.

Workarounds

Place the jobs API behind a reverse proxy that enforces mutual TLS or bearer-token authentication before requests reach /api/v1/runs.
Bind the PraisonAI jobs server to 127.0.0.1 and require an SSH tunnel or service mesh for access.
Apply network policies or host firewall rules to allow inbound traffic to the jobs port only from authorized clients.

bash

# Configuration example: restrict jobs API to localhost and require a reverse-proxy token
# systemd drop-in for the PraisonAI service
[Service]
Environment="PRAISONAI_JOBS_BIND=127.0.0.1"
Environment="PRAISONAI_AUTH_TOKEN=$(cat /etc/praisonai/auth.token)"

# nginx snippet enforcing bearer auth before proxying
location /api/v1/runs/ {
    if ($http_authorization != "Bearer <REPLACE_WITH_TOKEN>") { return 401; }
    proxy_pass http://127.0.0.1:8000;
}