GHSA-892r-p3jq-jp24: PraisonAI AgentOS: unauth remote agent invocation (CVSS 9.8)

# AgentOS remains unauthenticated after GHSA-pm96 patched version and allows remote agent invocation ## Summary PraisonAI's `AgentOS` FastAPI deployment surface remains unauthenticated in current main and in releases after the published patched version for `GHSA-pm96-6xpr-978x` / `CVE-2026-40151`. The public AgentOS advisory is published as an instruction-disclosure issue with affected versions `< 4.5.128` and patched version `4.5.128`. However, `v4.5.128`, latest release `v4.6.57`, and current main still register `GET /api/agents` and `POST /api/chat` without authentication. The chat route directly calls `agent.chat(request.message)`. No-auth and wrong-bearer requests both execute the deployed agent. This is broader than passive metadata disclosure. In any deployment where AgentOS wraps agents with tools, private context, memory, API integrations, or cost-bearing model calls, an unauthenticated reachable client can drive those agents. ## Affected Product - Repository: `MervinPraison/PraisonAI` - Package: `praisonai` - Component: `src/praisonai/praisonai/app/agentos.py` - Config component: `src/praisonai-agents/praisonaiagents/app/config.py` - Public advisory incomplete-fix reference: `GHSA-pm96-6xpr-978x` / `CVE-2026-40151` Confirmed affected dynamically: - `v4.5.126` - `v4.5.128` (published patched version for `GHSA-pm96-6xpr-978x`) - `v4.6.9` - `v4.6.10` - `v4.6.56` - `v4.6.57` - current main `2f9677abb2ea68eab864ee8b6a828fd0141612e1` Static source review found the same unauthenticated route pattern and `0.0.0.0` default in `v4.2.1`. Suggested affected range: `>= 4.2.1, <= 4.6.57`. ## Root Cause `AgentOSConfig` / `AgentAppConfig` defaults the deployment host to all interfaces and has no authentication fields: ```python name: str = "PraisonAI App" host: str = "0.0.0.0" port: int = 8000 api_prefix: str = "/api" ``` `AgentOS._register_routes()` registers public agent metadata and chat routes without middleware, dependency, API key check, bearer-token check, or startup fail-closed guard: ```python @app.get(f"{self.config.api_prefix}/agents") async def list_agents(): return {"agents": [...]} @app.post(f"{self.config.api_prefix}/chat", response_model=ChatResponse) async def chat(request: ChatRequest): ... response = agent.chat(request.message) ``` A wrong `Authorization` header is ignored because the route does not inspect it. Current main also has a root-export bug where `from praisonai import AgentOS` raises `ImportError`, but this does not mitigate the issue. The same class remains reachable through `from praisonai import AgentApp` and `from praisonai.app import AgentOS`. ## Why This Is Not Intended Behavior PraisonAI's security documentation says API servers were hardened so anonymous requests return `401` and default binding changed from `0.0.0.0` to `127.0.0.1` after the prior unauthenticated API server class. The API Server Authentication docs say bearer auth is enabled by default, disabling auth is not recommended for production, and `0.0.0.0` should be used only behind an authenticating proxy. The local PoV includes a hardened sibling control for the generated deploy API on current main. It returns: - no auth: `401` - wrong bearer: `401` - correct bearer: `200` AgentOS remains outside that control plane and still accepts no-auth and wrong-bearer `/api/chat` requests. ## Local PoV The PoV is local-only. It uses FastAPI's in-process test client, a stub agent, and a temporary file side effect. It does not start a network listener, call an LLM provider, or contact any external service. Command: ```bash env PYTHONPATH="artifacts/repos/praisonai-current/src/praisonai:artifacts/repos/praisonai-current/src/praisonai-agents" \ uv run --with fastapi --with httpx --with flask --with flask-cors \ --with pydantic --with typing-extensions --with rich --with python-dotenv \ submission-bundle/praisonai-prai-cand-007-agentos-incomplete-auth-fix/poc/prai_cand_007_agentos_incomplete_auth_fix.py \ --repo artifacts/repos/praisonai-current \ --label current-head ``` Current-head result summary: ```json { "describe": "v4.6.57-4-g2f9677ab", "head": "2f9677abb2ea68eab864ee8b6a828fd0141612e1", "agentos_vulnerable": true, "entrypoints": [ { "entrypoint": "agentapp_alias", "statuses": [200, 200, 200], "side_effects": ["no-auth-marker", "wrong-bearer-marker"] }, { "entrypoint": "direct_agentos", "statuses": [200, 200, 200], "side_effects": ["no-auth-marker", "wrong-bearer-marker"] } ], "deploy_api_control": { "control_passed": true, "statuses": [401, 401, 200] } } ``` The three AgentOS statuses are for: - unauthenticated `GET /api/agents`; - unauthenticated `POST /api/chat`; - wrong-bearer `POST /api/chat`. The side-effect list proves both unauthenticated chat requests invoked the agent method. Minimal inline reproducer: ```python from pathlib import Path from tempfile import TemporaryDirectory from fastapi.testclient import TestClient from praisonai import AgentApp from praisonaiagents import AgentOSConfig class StubAgent: name = "pov_agentos_agent" role = "tester" instructions = "private instruction marker" def __init__(self, out): self.out = out def chat(self, message): self.out.write_text(self.out.read_text() + message + "\n") return "PRAI_CAND_007_AGENTOS_EXECUTED:" + message with TemporaryDirectory() as tmp: side_effect = Path(tmp) / "side_effects.txt" side_effect.write_text("") app = AgentApp( agents=[StubAgent(side_effect)], config=AgentOSConfig(host="0.0.0.0", port=8000), ) client = TestClient(app.get_app()) assert client.get("/api/agents").status_code == 200 assert client.post("/api/chat", json={"message": "no-auth"}).status_code == 200 assert client.post( "/api/chat", headers={"Authorization": "Bearer definitely-wrong"}, json={"message": "wrong-bearer"}, ).status_code == 200 assert side_effect.read_text().splitlines() == ["no-auth", "wrong-bearer"] ``` ## Version Sweep | Target | Result | | --- | --- | | `v4.5.126` | vulnerable | | `v4.5.128` | vulnerable | | `v4.6.9` | vulnerable | | `v4.6.10` | vulnerable | | `v4.6.56` | vulnerable; generated deploy API control returns `401/401/200` | | `v4.6.57` | vulnerable; generated deploy API control returns `401/401/200` | | current `2f9677abb` | vulnerable; generated deploy API control returns `401/401/200` | Evidence files are retained locally under the bundle's `evidence/` directory and can be provided if useful. ## Duplicate / Incomplete-Fix Notes This report is related to `GHSA-pm96-6xpr-978x` / `CVE-2026-40151`. The published advisory describes AgentOS instruction disclosure and lists `4.5.128` as patched. It also mentions unauthenticated `/api/chat` as a chained instruction-extraction path. The current report should be treated as an incomplete fix / affected-range correction with a broader demonstrated impact: - the published patched version `v4.5.128` still reproduces; - latest release `v4.6.57` still reproduces; - current main still reproduces; - the PoV proves unauthorized agent invocation and side effects, not only instruction disclosure. This is distinct from private `PRAI-CAND-003` / `GHSA-x8cv-xmq7-p8xp`, which covers `praisonaiagents.AgentTeam.launch()` routes. This report covers `praisonai.app.AgentOS` and `AgentApp` alias routes. ## Impact If an operator exposes an AgentOS app on a reachable interface, any client that can reach it can: - enumerate deployed agents through `GET /api/agents`; - read agent names, roles, and instruction snippets; - invoke the default agent or a named agent through `POST /api/chat`; - trigger downstream tools, private context reads, memory accesses, API integrations, browser actions, or other side effects attached to the agent; - consume model/API budget through repeated invocation. The exact downstream impact depends on the deployed agents. The framework-level boundary failure is that a production deployment surface exposes agent control without authentication and defaults to binding on all interfaces. ## Suggested Fix Use the same security model already applied to generated API deployments: - add authentication fields to `AgentOSConfig` / `AgentAppConfig`; - default auth to enabled; - default bind host to `127.0.0.1`; - reject no-auth and wrong-bearer requests for `GET /api/agents` and `POST /api/chat`; - fail closed for non-loopback binds unless auth is configured or an explicit unsafe development opt-out is set; - avoid returning instruction text from unauthenticated metadata endpoints; - add regression tests for no auth, wrong bearer, correct bearer, and external bind without auth. Maintainers can either update `GHSA-pm96-6xpr-978x` with the corrected affected range and broader impact or publish a separate incomplete-fix advisory. ## Suggested Severity Suggested severity: Critical. The Critical score matches the unauthenticated agent-control model: network attacker, low complexity, no privileges, no user interaction, and high deployment-dependent impact when agents are connected to tools, private data, or cost-bearing services. If maintainers score only a minimal no-tool demo agent, the impact may be lower, but the current default framework behavior is still unauthenticated agent invocation.

An adversary conducting reconnaissance against an organization's AI infrastructure performs a targeted internet scan for FastAPI servers on port 8000 responding with PraisonAI-characteristic JSON. Against a discovered instance, they issue `GET /api/agents` with no credentials, receiving a list of deployed agents including names, roles, and instruction snippets that reveal private business context, connected tool capabilities, and model configuration. The adversary then crafts a sequence of unauthenticated `POST /api/chat` requests — first probing the agent's tool access by asking it to list available files or query a connected database, then exfiltrating the results in subsequent responses. If the agent has browser-use or code-execution tools, the attacker pivots to remote code execution on the host. Throughout the attack, every model call is billed to the victim's API keys embedded in the deployment environment, enabling concurrent cost-harvesting. The incomplete-fix history means the operator is likely unaware they are still exposed after applying what they believed was the security patch.