The AgentServer component in PraisonAI fails to enforce the declared auth_token on any of its routes. The result is an authentication bypass that allows any caller—including unauthenticated or unauthorised clients—to subscribe, publish, and execute other privileged actions as if they had a valid bearer token or X‑Auth‑Token, even when authentication is explicitly enabled in configuration. This weakness belongs to the missing‑authentication and missing‑authorization classes (CWE‑306 and CWE‑862) and effectively removes the primary gate that protects sensitive operations. Consequently an attacker can read confidential data, inject messages, or manipulate the multi‑agent system without possessing a valid credential, which threatens confidentiality, integrity, and availability of the platform. The likely attack vector is a network‑based HTTP request to the exposed API endpoints. Because the component advertises an auth_token field yet never checks it, the vulnerability can be triggered remotely by any party that can send HTTP traffic to the AgentServer. The lack of enforcement means the system does not validate the presence or validity of the token, permitting bypass from external actors. Impact on the business is significant: compromised messages, unauthorized actions, and potential exposure of sensitive data across all agents that rely on the AgentServer. Remote attackers can thereby commandeer or disrupt team collaboration, effectively compromising the entire application ecosystem without needing privileged credentials.

Vendors: MervinPraison Products: PraisonAI and praisonaiagents Affected versions: all releases prior to praisonaiagents 1.6.58; the vulnerability is fixed in the 1.6.58 release and later.

The CVSS score of 8.2 classifies this vulnerability as high severity. The EPSS score is unavailable, and the vulnerability is not listed in the CISA KEV catalog, indicating it may not yet have widespread exploitation. However, the remote nature of the flaw and the absence of any access control on the routes provide an attractive entry point for attackers. An attacker with network access to the AgentServer can simply issue authenticated‑like requests, defeat the authentication model, and gain full control over protected operations. No additional exploitation prerequisites are required beyond the ability to reach the API, and the issue is fixed in version 1.6.58. Until the patch is applied, the risk remains high, particularly for environments that expose the AgentServer to untrusted networks.