CVE-2026-57116

PraisonAI is a multi-agent teams system. From version 4.2.1 to before version 4.6.59, 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 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. This issue has been patched in version 4.6.59.

PraisonAI is a multi-agent teams system. From version 4.2.1 to before version 4.6.59, 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 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. This issue has been patched in version 4.6.59.

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:

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:

@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:

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 \
   …

PraisonAI is a multi-agent teams system. From version 4.2.1 to before version 4.6.59, 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 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. This issue has been patched in version 4.6.59.

PraisonAI is a multi-agent teams system. From version 4.2.1 to before version 4.6.59, 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 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. This issue has been patched in version 4.6.59.

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:

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:

@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:

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 \
   …

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:

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:

@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:

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 \
   …