CVE-2026-57127: PraisonAI Authentication Bypass Vulnerability

CVE-2026-57127 Overview

PraisonAI is a multi-agent teams system used to build and deploy autonomous AI agents. Versions prior to 4.6.58 contain an authentication bypass in the recipe serve command. When an operator selects api-key or JWT authentication, PraisonAI installs APIKeyAuthMiddleware or JWTAuthMiddleware. However, each middleware forwards requests when PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET and the corresponding recipe value are absent. Unauthenticated clients can reach recipe execution, input, and output surfaces. Attackers may trigger connected tools despite the operator explicitly enabling authentication. The issue is fixed in version 4.6.58.

Critical Impact

Unauthenticated remote attackers can execute recipes and invoke connected tools on PraisonAI servers, bypassing operator-configured authentication controls.

Affected Products

• PraisonAI versions prior to 4.6.58
• PraisonAI recipe serve deployments using API-key authentication
• PraisonAI recipe serve deployments using JWT authentication

Discovery Timeline

• 2026-09-14 - CVE-2026-57127 published to the National Vulnerability Database (NVD)
• 2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-57127

Vulnerability Analysis

The vulnerability is categorized as Missing Authentication for Critical Function [CWE-306]. PraisonAI's recipe serve subcommand exposes HTTP endpoints for recipe execution and tool invocation. Operators can enable API-key or JWT authentication through configuration. When enabled, PraisonAI registers APIKeyAuthMiddleware or JWTAuthMiddleware into the request pipeline.

The middleware performs a defensive check for the presence of environment secrets (PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET) and the corresponding recipe-level value. If either input is missing, the middleware falls through and forwards the request without validation. This fail-open behavior converts a misconfiguration into a full authentication bypass. Downstream handlers process recipe inputs and outputs as if the request were authenticated.

An attacker reaching the network-exposed service can invoke recipes and any tools connected to those recipes. In multi-agent deployments this may include file system access, external API calls, or command execution through agent tools.

Root Cause

The middleware treats absent configuration as an implicit "authentication disabled" signal instead of a fatal startup error. Both APIKeyAuthMiddleware and JWTAuthMiddleware short-circuit their validation logic when secrets are not configured at runtime, contradicting the operator's explicit intent to enable authentication.

Attack Vector

Exploitation requires only network access to a vulnerable recipe serve endpoint. No credentials, user interaction, or privileges are required. An attacker sends an unauthenticated HTTP request directly to recipe execution or input endpoints. The middleware forwards the request, and the agent framework processes it as trusted input.

# Patch excerpt from server.py - bearer token validation
# Source: https://github.com/MervinPraison/PraisonAI/commit/2f9677abb2ea68eab864ee8b6a828fd0141612e1

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

The companion patch in file_memory.py hardens user_id handling to reject path traversal sequences before they are used as directory names:

# Source: https://github.com/MervinPraison/PraisonAI/commit/2f9677abb2ea68eab864ee8b6a828fd0141612e1

@staticmethod
def _sanitise_user_id(user_id: str) -> str:
    """Reject path traversal in user_id before using it as a directory name."""
    if not user_id or not isinstance(user_id, str):
        return "default"
    if ".." in user_id or "/" in user_id or "\\" in user_id:
        raise ValueError("user_id must not contain path separators or parent references")
    safe = user_id.strip()
    return safe or "default"

Detection Methods for CVE-2026-57127

Indicators of Compromise

• HTTP requests to PraisonAI recipe endpoints lacking Authorization or X-Auth-Token headers that receive HTTP 200 responses
• Recipe execution logs showing invocations from unexpected source IP addresses
• Outbound connections initiated by agent tools that do not correlate with authenticated user sessions
• PraisonAI process startup logs indicating auth middleware loaded but PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET unset

Detection Strategies

• Inventory all PraisonAI installations and query the running version to identify hosts below 4.6.58
• Audit environment variables on PraisonAI hosts to confirm that PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET are set when auth is enabled
• Review reverse proxy and application access logs for anonymous requests to /recipe, /input, or /output paths

Monitoring Recommendations

• Alert on any PraisonAI recipe execution request that lacks a valid bearer token in access logs
• Baseline expected client IP ranges for the agent API and alert on deviations
• Monitor child processes and outbound network calls from the PraisonAI process to detect unexpected tool invocation

How to Mitigate CVE-2026-57127

Immediate Actions Required

• Upgrade PraisonAI to version 4.6.58 or later on all hosts running recipe serve
• Restrict network exposure of PraisonAI endpoints to trusted networks or a VPN until patching is complete
• Rotate any API keys, JWT secrets, or downstream tool credentials that may have been exposed through unauthenticated recipe execution
• Review recipe execution history for unauthorized invocations since the service was first deployed

Patch Information

The fix is available in PraisonAI v4.6.58. Details are documented in GHSA-j4hj-7hfh-g2f4 with the code change in commit 2f9677a. The patch enforces bearer token validation and adds input sanitization for user_id fields.

Workarounds

• Place PraisonAI behind a reverse proxy that enforces authentication independently of the application middleware
• Bind the recipe serve listener to 127.0.0.1 and tunnel access through SSH or a mutually authenticated gateway
• Verify at process start that PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET and the recipe-level value are both non-empty before exposing the service

# Verify PraisonAI version and required auth secrets before starting recipe serve
pip show praisonai | grep -i version

if [ -z "$PRAISONAI_API_KEY" ] && [ -z "$PRAISONAI_JWT_SECRET" ]; then
  echo "ERROR: authentication secret not set; refusing to start" >&2
  exit 1
fi

praisonai recipe serve --host 127.0.0.1 --port 8000