CVE-2026-55538 in PraisonAIinfo

Summary

by MITRE • 08/25/2026

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, praisonai serve agents parses config["api_key"] but _create_agents_app() does not authenticate POST /agents or POST /agents/{agent_name}. Missing or incorrect bearer and X-API-Key values still reach agent execution. This issue is fixed in version 4.6.58.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 08/25/2026

The vulnerability identified in PraisonAI versions prior to 4.6.51 represents a critical authentication bypass within the multi-agent team orchestration system. PraisonAI functions as an agentic framework where multiple AI agents collaborate, often requiring secure API endpoints for inter-service communication and external integration. The core flaw lies in the inconsistency between configuration parsing and request handling logic. Specifically, while the application correctly parses the api_key from its configuration file during initialization via the serve_agents function, this credential validation is not enforced at the entry points of the agent execution APIs.

The technical root cause is located within the _create_agents_app() method which establishes the FastAPI or similar web framework routes for POST /agents and POST /agents/{agent_name}. These endpoints are designed to accept requests that trigger specific AI agent behaviors, such as task assignment or data processing. However, these handlers fail to validate the presence of a valid Bearer token in the Authorization header or an X-API-Key value before proceeding with execution logic. Consequently, any client capable of reaching the network interface hosting PraisonAI can invoke these endpoints without providing credentials that match the configured api_key. This effectively renders the authentication mechanism inert for agent-specific operations, allowing unauthenticated actors to interact directly with the underlying AI models and tools exposed by the agents.

The operational impact of this vulnerability is severe due to the nature of agentic systems which often possess elevated privileges or access to sensitive data sources. An attacker exploiting this flaw can execute arbitrary commands through the AI agents, potentially leading to unauthorized data exfiltration, manipulation of application state, or further lateral movement within a connected network if the agents have permissions to interact with other services. Since the vulnerability allows unauthenticated POST requests, it also facilitates denial-of-service attacks by flooding the system with resource-intensive agent tasks. Furthermore, in environments where PraisonAI is used for automated workflows involving financial transactions, personal data processing, or infrastructure management, this lack of access control could result in significant regulatory compliance violations and substantial business disruption.

This issue aligns with CWE-287, which describes Improper Authentication, as the system fails to properly verify the identity of users attempting to perform privileged actions. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, specifically in the context of misconfigured or bypassed authentication controls that allow unauthorized access to resources. The vulnerability persists until version 4.6.58 where the developers corrected the middleware chain and request handlers to ensure that all incoming requests to agent endpoints are subjected to rigorous authentication checks against the configured API keys.

To mitigate this risk, organizations running PraisonAI must immediately upgrade to version 4.6.58 or later. For environments where an immediate upgrade is not feasible due to dependency constraints, temporary mitigations should include placing a reverse proxy such as Nginx or Apache in front of the application to enforce authentication at the network level before requests reach the Python application layer. Additionally, restricting access to the PraisonAI service ports via firewall rules to only trusted IP addresses can reduce the attack surface until the software is patched. It is also recommended to audit logs for any suspicious POST activity directed at agent endpoints during the window of exposure to assess potential compromise and ensure that no unauthorized actions were executed through this vulnerability.

Responsible

GitHub M

Reservation

06/17/2026

Disclosure

08/25/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!