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 \
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:
{
"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:
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.
References
AgentOS remains unauthenticated after GHSA-pm96 patched version and allows remote agent invocation
Summary
PraisonAI's
AgentOSFastAPI deployment surface remains unauthenticated incurrent 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.128and patched version4.5.128. However,v4.5.128, latest releasev4.6.57, and current main still registerGET /api/agentsandPOST /api/chatwithout authentication. The chat routedirectly calls
agent.chat(request.message). No-auth and wrong-bearer requestsboth 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
MervinPraison/PraisonAIpraisonaisrc/praisonai/praisonai/app/agentos.pysrc/praisonai-agents/praisonaiagents/app/config.pyGHSA-pm96-6xpr-978x/CVE-2026-40151Confirmed affected dynamically:
v4.5.126v4.5.128(published patched version forGHSA-pm96-6xpr-978x)v4.6.9v4.6.10v4.6.56v4.6.572f9677abb2ea68eab864ee8b6a828fd0141612e1Static source review found the same unauthenticated route pattern and
0.0.0.0default inv4.2.1.Suggested affected range:
>= 4.2.1, <= 4.6.57.Root Cause
AgentOSConfig/AgentAppConfigdefaults the deployment host to allinterfaces and has no authentication fields:
AgentOS._register_routes()registers public agent metadata and chat routeswithout middleware, dependency, API key check, bearer-token check, or startup
fail-closed guard:
A wrong
Authorizationheader is ignored because the route does not inspect it.Current main also has a root-export bug where
from praisonai import AgentOSraises
ImportError, but this does not mitigate the issue. The same classremains reachable through
from praisonai import AgentAppandfrom praisonai.app import AgentOS.Why This Is Not Intended Behavior
PraisonAI's security documentation says API servers were hardened so anonymous
requests return
401and default binding changed from0.0.0.0to127.0.0.1after 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.0should be usedonly behind an authenticating proxy.
The local PoV includes a hardened sibling control for the generated deploy API
on current main. It returns:
401401200AgentOS remains outside that control plane and still accepts no-auth and
wrong-bearer
/api/chatrequests.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 \ 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-headCurrent-head result summary:
{ "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:
GET /api/agents;POST /api/chat;POST /api/chat.The side-effect list proves both unauthenticated chat requests invoked the
agent method.
Minimal inline reproducer:
Version Sweep
v4.5.126v4.5.128v4.6.9v4.6.10v4.6.56401/401/200v4.6.57401/401/2002f9677abb401/401/200Evidence files are retained locally under the bundle's
evidence/directoryand can be provided if useful.
Duplicate / Incomplete-Fix Notes
This report is related to
GHSA-pm96-6xpr-978x/CVE-2026-40151. Thepublished advisory describes AgentOS instruction disclosure and lists
4.5.128as patched. It also mentions unauthenticated/api/chatas a chainedinstruction-extraction path.
The current report should be treated as an incomplete fix / affected-range
correction with a broader demonstrated impact:
v4.5.128still reproduces;v4.6.57still reproduces;instruction disclosure.
This is distinct from private
PRAI-CAND-003/GHSA-x8cv-xmq7-p8xp, whichcovers
praisonaiagents.AgentTeam.launch()routes. This report coverspraisonai.app.AgentOSandAgentAppalias routes.Impact
If an operator exposes an AgentOS app on a reachable interface, any client that
can reach it can:
GET /api/agents;POST /api/chat;integrations, browser actions, or other side effects attached to the agent;
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:
AgentOSConfig/AgentAppConfig;127.0.0.1;GET /api/agentsandPOST /api/chat;unsafe development opt-out is set;
bind without auth.
Maintainers can either update
GHSA-pm96-6xpr-978xwith the corrected affectedrange 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.
References