CVE-2026-47393: PraisonAI Auth Bypass Vulnerability

CVE-2026-47393 Overview

PraisonAI is a multi-agent orchestration framework used to build and deploy teams of large language model (LLM) agents. CVE-2026-47393 documents that the framework's built-in code generator, praisonai.deploy.api.generate_api_server_code, emits a Flask API server with authentication disabled by default. Users following the documented quickstart (praisonai deploy --type api) receive a server that binds to 0.0.0.0, exposes /chat and /agents endpoints, and executes praisonai.run() on attacker-supplied JSON input. The generated server has full access to LLM API key material present in the process environment. Versions prior to 4.6.40 ship the generator with auth_enabled defaulting to False.

Critical Impact
Unauthenticated network attackers can invoke agent execution, exhaust LLM API credits, and abuse tools connected to the agent framework on any exposed PraisonAI deployment.

Affected Products

PraisonAI versions prior to 4.6.40
Deployments generated by praisonai deploy --type api
Flask API servers emitted by praisonai.deploy.api.generate_api_server_code

Discovery Timeline

2026-07-21 - CVE-2026-47393 published to the National Vulnerability Database (NVD)
2026-07-22 - Last updated in the NVD database

Technical Details for CVE-2026-47393

Vulnerability Analysis

The issue is classified as Missing Authentication for Critical Function [CWE-306]. The generate_api_server_code function emits a Flask application that accepts JSON payloads at /chat and /agents and passes them directly to praisonai.run(). The generator defaults auth_enabled to False, so the emitted server performs no token check before invoking agent orchestration.

The documented quickstart YAML binds the generated server to 0.0.0.0, exposing it on every network interface. Any client that can reach the listener can trigger LLM calls under the operator's API keys and drive any tools wired into the agent graph. Because agent workflows commonly execute code, browse URLs, or invoke shell tools, unauthenticated access frequently escalates into arbitrary command execution against the host or downstream services.

Root Cause

The root cause is an insecure default in a code generator. The template that produces the deployable Flask server sets auth_enabled=False and does not wrap /chat or /agents in an authentication decorator. Operators who follow the documented workflow inherit this default without warning.

Attack Vector

Exploitation requires only network reach to the exposed listener. An attacker sends an HTTP POST to /chat or /agents with a JSON body describing the prompt or agent invocation, and the server executes the orchestration path with production credentials.

python

# Illustrative unauthenticated request against a vulnerable deployment
# POST /chat HTTP/1.1
# Host: victim.example:8000
# Content-Type: application/json
#
# {"message": "...attacker-controlled prompt..."}

The upstream security hardening batch (pull request #1685) also replaced unsafe eval() usage in example tools with an AST-validated evaluator, illustrating the downstream tool risk once an attacker reaches the agent surface:

python

def _safe_calc(expr: str) -> str:
    import ast
    allowed = set("0123456789+-*/.() ")
    if not all(c in allowed for c in expr):
        return "error"
    try:
        tree = ast.parse(expr, mode="eval")
        for node in ast.walk(tree):
            if not isinstance(
                node,
                (
                    ast.Expression,
                    ast.BinOp,
                    ast.UnaryOp,
                    ast.Constant,
                    ast.Add,
                    ast.Sub,
                    ast.Mult,
                    ast.Div,
                    ast.USub,
                    ast.UAdd,
                ),
            ):
                return "error"

Source: PraisonAI commit ef79b7a

Detection Methods for CVE-2026-47393

Indicators of Compromise

Flask process listening on 0.0.0.0 with routes /chat and /agents and no Authorization header requirement
Outbound spikes to LLM providers (OpenAI, Anthropic, Google) from a PraisonAI host correlated with inbound requests from untrusted IPs
Access log entries showing successful POST /chat or POST /agents responses from external IP ranges
Presence of an APIConfig instance with auth_enabled=False in deployed configuration files

Detection Strategies

Inventory running Python processes for praisonai deploy command lines and generated server modules from versions prior to 4.6.40
Perform authenticated network scanning to enumerate /agents endpoints that respond with HTTP 200 to unauthenticated GET or POST requests
Search source repositories and container images for the generate_api_server_code template and validate the auth_enabled value

Monitoring Recommendations

Alert on LLM API usage anomalies against billing baselines for keys used by PraisonAI service accounts
Log every request to /chat and /agents with source IP, request size, and response code, and forward to a centralized SIEM
Monitor egress from PraisonAI hosts for connections to unexpected destinations initiated by agent tool executions

How to Mitigate CVE-2026-47393

Immediate Actions Required

Upgrade PraisonAI to version 4.6.40 or later, which changes the generator to require explicit opt-in for unauthenticated mode
Regenerate any previously deployed API servers after upgrade, since the vulnerable code was emitted at deploy time and persists in on-disk artifacts
Restrict network exposure of existing deployments to trusted management networks until they are rebuilt
Rotate LLM provider API keys and any downstream tool credentials that were reachable from the exposed process environment

Patch Information

The fix is delivered in PraisonAI 4.6.40 via pull request #1685 and commit ef79b7a. Operators enable authentication by constructing APIConfig(auth_enabled=True, auth_token=...) and passing it to the deploy workflow. Additional context is available in the GitHub Security Advisory GHSA-8444-4fhq-fxpq and the related GHSA-6rmh-7xcm-cpxj advisory.

Workarounds

Bind the Flask server to 127.0.0.1 and expose it only through an authenticating reverse proxy that enforces mutual TLS or bearer tokens
Place the deployment behind a network policy or security group that permits only allow-listed client IPs
Wrap /chat and /agents with a WSGI middleware that validates a shared secret header before dispatching to the route handler

bash

# Explicitly enable authentication when generating an API server
python - <<'PY'
from praisonai.deploy.api import APIConfig, generate_api_server_code

config = APIConfig(
    auth_enabled=True,
    auth_token="REPLACE_WITH_A_LONG_RANDOM_SECRET",
)
generate_api_server_code(config=config)
PY