AI Threat AlertCVE-2026-55538: PraisonAI: missing auth allows agent execution
GHSA-r7v3-x45f-g7hpHIGHPoC AVAILABLECISA: TRACK*PraisonAI's HTTP agent-serving API accepts requests to run configured multi-agent teams even when the caller sends no bearer token or an invalid X-API-Key header, because the API key check that _create_agents_app() parses from config is never actually enforced on the POST /agents and POST /agents/{agent_name} routes. With CVSS 7.3 and zero prerequisites — no privileges, no user interaction, network-reachable — any internet-facing PraisonAI serve instance lets an anonymous caller trigger arbitrary configured agent executions, which in agent frameworks typically means invoking whatever tools, APIs, or data sources those agents are wired to. There's no confirmed public exploit or CISA KEV listing yet and EPSS data isn't available, but the flaw is trivial to weaponize (a single unauthenticated POST) and this package already carries 153 other CVEs with a package risk score of 0/100, suggesting a broadly weak security posture that warrants extra scrutiny beyond this one fix. Patch to praisonai 4.6.58 or later immediately; until then, put any exposed /agents endpoint behind a reverse-proxy auth layer or network ACL, and audit access logs for POST requests to /agents lacking a valid Authorization/X-API-Key header.
What is the risk?
High exploitability: the bypass requires a single unauthenticated HTTP request with no privileges, no user interaction, and low attack complexity (AV:N/AC:L/PR:N/UI:N) against any network-reachable praisonai serve instance. Declared CVSS impact is bounded (C:L/I:L/A:L), but the real-world severity depends heavily on what the exposed agents are configured to do — if they have tool access to internal systems, credentials, or external integrations, unauthorized invocation can cascade well beyond what the CVSS vector implies. No active-exploitation signals exist today (not in CISA KEV, no EPSS score, no public PoC, no Nuclei template), which lowers near-term urgency, but any internet-exposed instance should be treated as immediately exploitable given the trivial attack path.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| PraisonAI | pip | < 4.6.58 | 4.6.58 |
Do you use PraisonAI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade to praisonai >= 4.6.58, which fixes the missing authentication check in _create_agents_app(). 2) Until patched, do not expose the PraisonAI serve API directly to the internet — front it with a reverse proxy or API gateway that enforces its own authentication, or restrict access via network ACL/VPN/firewall. 3) After upgrading, verify the fix by confirming POST /agents and POST /agents/{agent_name} reject requests with missing or invalid bearer/X-API-Key values (expect 401/403). 4) Review historical access logs for POST requests to /agents* endpoints lacking valid auth headers to check for prior exploitation. 5) Given the package's high CVE count (153) and 0/100 risk score, consider a broader security review of the PraisonAI deployment rather than treating this as an isolated fix.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-55538?
PraisonAI's HTTP agent-serving API accepts requests to run configured multi-agent teams even when the caller sends no bearer token or an invalid X-API-Key header, because the API key check that _create_agents_app() parses from config is never actually enforced on the POST /agents and POST /agents/{agent_name} routes. With CVSS 7.3 and zero prerequisites — no privileges, no user interaction, network-reachable — any internet-facing PraisonAI serve instance lets an anonymous caller trigger arbitrary configured agent executions, which in agent frameworks typically means invoking whatever tools, APIs, or data sources those agents are wired to. There's no confirmed public exploit or CISA KEV listing yet and EPSS data isn't available, but the flaw is trivial to weaponize (a single unauthenticated POST) and this package already carries 153 other CVEs with a package risk score of 0/100, suggesting a broadly weak security posture that warrants extra scrutiny beyond this one fix. Patch to praisonai 4.6.58 or later immediately; until then, put any exposed /agents endpoint behind a reverse-proxy auth layer or network ACL, and audit access logs for POST requests to /agents lacking a valid Authorization/X-API-Key header.
Is CVE-2026-55538 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-55538, increasing the risk of exploitation.
How to fix CVE-2026-55538?
1) Upgrade to praisonai >= 4.6.58, which fixes the missing authentication check in _create_agents_app(). 2) Until patched, do not expose the PraisonAI serve API directly to the internet — front it with a reverse proxy or API gateway that enforces its own authentication, or restrict access via network ACL/VPN/firewall. 3) After upgrading, verify the fix by confirming POST /agents and POST /agents/{agent_name} reject requests with missing or invalid bearer/X-API-Key values (expect 401/403). 4) Review historical access logs for POST requests to /agents* endpoints lacking valid auth headers to check for prior exploitation. 5) Given the package's high CVE count (153) and 0/100 risk score, consider a broader security review of the PraisonAI deployment rather than treating this as an isolated fix.
What systems are affected by CVE-2026-55538?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, AI agent APIs, agentic tool invocation.
What is the CVSS score for CVE-2026-55538?
CVE-2026-55538 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.45%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049Exploit Public-Facing ApplicationAML.T0053AI Agent Tool InvocationCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An organization runs `praisonai serve` to expose an internal agent team — for example, one with access to a ticketing system, a code repository, or an internal knowledge base — via a REST API, believing the api_key setting in its config protects it. An attacker scanning for exposed AI agent endpoints discovers the service, sends a POST request to /agents/{agent_name} with no Authorization header or a garbage X-API-Key value, and the request still reaches the agent execution logic. The attacker can now invoke the agent's configured tools directly — instructing it to read internal files, call an integrated API, or take other actions the agent is authorized to perform on the organization's behalf — all without any valid credential, turning an assumed-protected internal automation into an open door.
Weaknesses (CWE)
CWE-306Missing Authentication for Critical FunctionPrimaryCWE-306Missing Authentication for Critical FunctionPrimaryCWE-306Missing Authentication for Critical FunctionCWE-306 — Missing Authentication for Critical Function: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
- [Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate
- [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:LReferences
Timeline
Related Vulnerabilities
CVE-2026-4816810.0PraisonAI: shell injection in Claude Action enables RCE
Same package: praisonaiCVE-2026-6144710.0PraisonAI: RCE via unsandboxed LLM code execution
Same package: praisonaiCVE-2026-614459.9PraisonAI: AICoder root RCE via unsanitized tool calls
Same package: praisonaiGHSA-vmmj-pfw7-fjwp9.9praisonai: sandbox escape gives RCE via codeMode tool
Same package: praisonaiCVE-2026-473929.9praisonaiagents: RCE via Python sandbox bypass
Same package: praisonai