GHSA-892R-P3JQ-JP24

AgentOS remains unauthenticated after GHSA-pm96 patched version and allows remote agent invocation

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

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.

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.

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.

A critical operation is accessible without requiring any authentication. Typical impact: any user can invoke the privileged function.

GHSA-892R-P3JQ-JP24 has a CVSS score of 9.8 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.6.59); upgrading removes the vulnerable code path.

Kodem intelligence

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.

1. What is GHSA-892R-P3JQ-JP24? GHSA-892R-P3JQ-JP24 is a critical-severity missing authentication for critical function vulnerability in praisonai (pip), affecting versions >= 4.2.1, <= 4.6.57. It is fixed in 4.6.59. A critical operation is accessible without requiring any authentication.
2. How severe is GHSA-892R-P3JQ-JP24? GHSA-892R-P3JQ-JP24 has a CVSS score of 9.8 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of praisonai are affected by GHSA-892R-P3JQ-JP24? praisonai (pip) versions >= 4.2.1, <= 4.6.57 is affected.
4. Is there a fix for GHSA-892R-P3JQ-JP24? Yes. GHSA-892R-P3JQ-JP24 is fixed in 4.6.59. Upgrade to this version or later.
5. Is GHSA-892R-P3JQ-JP24 exploitable, and should I be worried? Whether GHSA-892R-P3JQ-JP24 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-892R-P3JQ-JP24 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-892R-P3JQ-JP24? Upgrade praisonai to 4.6.59 or later.

Other vulnerabilities in praisonai