CVE-2026-57140: PraisonAI AgentOS exposes unauthenticated agent listing and invocation
PraisonAI is a multi-agent teams system. From 1.6.0 until 1.7.2, AgentOS in src/praisonai-ts/src/os/agentos.ts uses the 0.0.0.0 default from src/praisonai-ts/src/os/config.ts and registers GET /api/agents and POST /api/chat without authentication middleware. A remote caller who can reach the service can obtain agent names, roles, and instruction prefixes and can invoke a selected agent, potentially reaching its tools, memory, external APIs, credentials, and workflow state. An initial remediation was released in version 1.7.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
PraisonAI AgentOSto a version that resolves this vulnerability.Fixed in 1.7.2 - Configuration
For versions from 1.6.0 until 1.7.2, add authentication middleware to the routes GET /api/agents and POST /api/chat (previously registered without authentication middleware).
PraisonAI AgentOS (src/praisonai-ts/src/os/agentos.ts) Authentication middleware for GET /api/agents and POST /api/chat = add authentication (enable middleware) - Configuration
For versions from 1.6.0 until 1.7.2, change the default host/bind configuration away from 0.0.0.0 in src/praisonai-ts/src/os/config.ts to prevent unauthenticated remote access. (Material states it uses the 0.0.0.0 default.)
PraisonAI AgentOS (src/praisonai-ts/src/os/config.ts) Default bind address/host = not 0.0.0.0 (remove default 0.0.0.0 exposure) - Compensating control
If affected versions (1.6.0–1.7.2) are still deployed, restrict network access to the service endpoints that expose GET /api/agents and POST /api/chat so only trusted callers can reach them.
Event History
Frequently Asked Questions
Which deployments are most exposed?
AgentOS deployments reachable by remote callers are exposed because the default bind address is 0.0.0.0. Systems bound only to a trusted network or localhost have a smaller exposure surface, but access controls still need to be verified.
Does exploitation require an account or user interaction?
No. The reported endpoint access has no authentication middleware, and the severity vector indicates no privileges or user interaction are required. An attacker only needs network reachability to the service.
What can an unauthenticated caller do?
A caller can retrieve agent names, roles, and instruction prefixes through the agent listing endpoint, then invoke a selected agent through the chat endpoint. Invoked agents may be able to reach configured tools, memory, external APIs, credentials, and workflow state.
What can be done if remediation cannot be applied immediately?
Restrict network access to AgentOS so untrusted remote callers cannot reach it, especially when it is bound to 0.0.0.0. Place the service behind access controls that enforce authentication and limit access to trusted users or networks.
How can I check whether an instance is affected?
Review whether the deployment runs a version from 1.6.0 through 1.7.2 and whether AgentOS is listening on a remotely reachable interface. Test or inspect the service configuration to determine whether GET /api/agents and POST /api/chat can be reached without authentication.