CVE-2026-55541

## Summary `praisonai serve agents` and `praisonai serve unified` both accept `--api-key` for authentication. The flag is parsed but never wired into the FastAPI app — no middleware, no header check, nothing. The server runs wide open regardless of what key you set. Tested on 4.6.50 from PyPI. ## Affected versions - Confirmed on **4.6.50** (current PyPI, 2026-06-02) - Likely since **4.6.34** when the serve subsystem shipped - File: `src/praisonai/praisonai/cli/features/serve.py` ## What happens The CLI defines `--api-key` in the arg spec (`serve.py:199`) and passes the parsed value into `_create_agents_app(config)`. But that function never reads `config["api_key"]`. The FastAPI app gets created with no auth at all. Same thing in `_create_unified_app`. The help text says `--api-key <key> API key for authentication`, so this isn't ambiguous — it's supposed to protect the server. It just doesn't. ``` $ grep -n "api_key" src/praisonai/praisonai/cli/features/serve.py 107: --api-key <key> API key for authentication 199: "api_key": {"default": None}, 847: "api_key": {"default": None}, ``` ## Endpoints exposed without auth - `POST /agents` — runs the full agent workflow - `POST /agents/{name}` — invokes a specific agent - `POST /api/v1/agents/{id}/invoke` — n8n integration endpoint - `GET /` — lists all endpoints - `GET /__praisonai__/discovery` — service discovery ## Not the same as CVE-2026-44338 CVE-2026-44338 was about the legacy `deploy/api.py` hardcoding `AUTH_ENABLED = False`. That was fixed in 4.6.34. This bug is in the newer `serve` subsystem that shipped in the same release — the `--api-key` flag exists but was never connected to anything. ## PoC ### Setup ```bash python3 -m venv /tmp/poc-venv /tmp/poc-venv/bin/pip install praisonai==4.6.50 fastapi starlette httpx pyyaml ``` ### Script ```python import sys, types, tempfile, os # Stub heavy deps so we only test the serve auth logic for m in ["praisonai.endpoints.discovery"