Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.4",
  "pubDate": "2026-09-15T11:17:11.473Z",
  "pubdate": "2026-09-15T11:17:11.473Z",
  "executiveSummary": "PraisonAI versions 1.6.0 through 1.7.2 are affected by an unauthenticated API access vulnerability originating from the AgentOS component. Due to a failure to implement authentication middleware on critical endpoints, unauthorized remote actors can access internal agent configurations and execute arbitrary tasks. The vulnerability stems from a default binding of the service to 0.0.0.0, exposing the internal API to any network-reachable entity. This security oversight allows attackers to perform unauthorized data exfiltration regarding agent roles and instructions, and potentially execute malicious workflows by invoking agent tools, external APIs, and accessing memory state. Given that the API lacks mandatory authentication, the risk level is high, as it enables full interaction with the agent ecosystem without valid credentials. Attackers require only network reachability to the service to exploit the exposed endpoints, making this a critical concern for deployments that are not segmented behind robust firewalls or secure gateways.",
  "technicalDetails": "The vulnerability resides within the AgentOS implementation located in src/praisonai-ts/src/os/agentos.ts, which relies on a default configuration in src/praisonai-ts/src/os/config.ts that binds the service to the 0.0.0.0 interface. This network configuration exposes the application's administrative and functional API endpoints to all available network interfaces rather than restricting access to localhost.\nThe primary security failure is the absence of authentication middleware for the GET /api/agents and POST /api/chat endpoints. In standard multi-agent systems, these endpoints represent sensitive control planes. By sending unauthenticated HTTP requests to these paths, a remote attacker can bypass access control checks that should be enforced to prevent unauthorized interaction with the underlying agent framework.\nThe attack flow proceeds as follows: First, an attacker identifies a reachable PraisonAI instance, typically via scanning for open ports bound to 0.0.0.0. Second, the attacker issues a GET request to /api/agents, which returns a structured response containing agent names, specific roles, and private instruction prefixes. This information allows the attacker to conduct reconnaissance on the agent's capabilities and internal instructions.\nThird, utilizing the information gained from the initial enumeration, the attacker crafts a POST request to /api/chat. Since the system lacks middleware validation, the request is processed as a legitimate command. The attacker can then trigger the selected agent to perform tasks. Because agents often possess elevated permissions to interact with external APIs, databases, or local memory, the attacker essentially gains an unauthorized execution proxy.\nThe post-exploitation impact is significant: an attacker can induce the agent to leak sensitive data stored in its memory, perform actions via integrated tools (such as file system operations or network requests), or manipulate the agent's workflow state to achieve persistence or perform secondary attacks within the host environment. The exposure of internal credentials or API keys that might be accessible to the agent's environment further elevates the risk of lateral movement within the network.\nThe vulnerability affects versions 1.6.0 through 1.7.2. An initial remediation was applied in version 1.7.2, though users should ensure their network topology is configured to deny unsolicited traffic to these service ports as a layer of defense-in-depth."
}