CVE-2026-55541: PraisonAI no auth on agent

CISO Take

PraisonAI's built-in serve mode exposes two HTTP endpoints, POST /agents and POST /api/v1/agents/{id}/invoke, without any credential check when the app is created via _create_agents_app() or _create_unified_app(), so anyone who can reach the service network-path can create new agents or invoke existing ones as if they were a legitimate operator. This is a low-effort, high-impact bug — CWE-862 Missing Authorization requires no exploit chain, no scanner or PoC exists yet, and it isn't in CISA KEV, but exploitability is trivial for anyone who finds an exposed instance since the fix is simply "add auth," implying none existed at all. Blast radius today looks limited (1 tracked downstream dependent and no severity score yet), but any team that ran `praisonai serve agents` or `praisonai serve unified parse --api-key` reachable from an untrusted network is fully exposed to unauthorized agent creation and invocation, which can translate into data exposure, tool abuse, or resource consumption depending on what tools/credentials the agents hold. Upgrade to praisonai 4.6.58 immediately; until patched, do not expose the serve endpoints to untrusted networks and front them with a reverse proxy enforcing authentication, and audit logs for POST requests to /agents or /api/v1/agents/*/invoke from unexpected sources.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Exploitability is high in relative terms: the vulnerability requires no authentication, no special tooling, and no AI/ML expertise — a simple unauthenticated HTTP POST is sufficient (sophistication: trivial). There is no public exploit or Nuclei template yet and it is not in CISA KEV, so opportunistic mass exploitation has not been observed, but the low complexity means that could change quickly once the advisory circulates. Actual impact depends heavily on deployment context: instances of `praisonai serve` exposed to the internet or to an internal untrusted network are the highest-risk scenario, since an attacker can both spin up arbitrary new agents and invoke existing ones, potentially triggering any tools, credentials, or downstream systems those agents are wired to. Overall risk should be treated as moderate-to-high for any organization running praisonai serve in production prior to 4.6.58, and low for organizations only using PraisonAI as an embedded library without the serve/API mode.

How does the attack unfold?

Discovery

Attacker identifies an exposed PraisonAI serve instance reachable over the network.

AML.T0006

Unauthenticated Access

Attacker sends a POST request to /agents or /api/v1/agents/{id}/invoke without any credentials, since no auth check is wired into the app.

AML.T0049

Agent Abuse

Attacker creates a rogue agent or invokes an existing one, triggering whatever tools/credentials it has configured.

AML.T0053

Impact

Downstream tool access enables data exposure, unauthorized actions, or resource abuse depending on the agent's configured capabilities.

Discovery

Attacker identifies an exposed PraisonAI serve instance reachable over the network.

AML.T0006

Unauthenticated Access

Attacker sends a POST request to /agents or /api/v1/agents/{id}/invoke without any credentials, since no auth check is wired into the app.

AML.T0049

Agent Abuse

Attacker creates a rogue agent or invokes an existing one, triggering whatever tools/credentials it has configured.

AML.T0053

Impact

Downstream tool access enables data exposure, unauthorized actions, or resource abuse depending on the agent's configured capabilities.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	< 4.6.58	`4.6.58`
1 dependents 69% patched ~12d to patch Full package profile →

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

Patch to praisonai >= 4.6.58, which fixes the missing credential check on both endpoints (see commit 2f9677a and release v4.6.58). Until patched: do not expose praisonai serve instances to the public internet or to untrusted internal segments — bind to localhost or a private network only, and place a reverse proxy (e.g. Nginx/Caddy) in front that enforces authentication (API key header, mTLS, or basic auth) before requests reach the app. For detection, review access/proxy logs for unexpected POST requests to /agents or /api/v1/agents/{id}/invoke from source IPs outside your known automation/CI ranges, and review any agents that were created or invoked outside expected maintenance windows. After patching, verify the new version actually enforces the --api-key flag / credential check by testing an unauthenticated request returns 401/403.

How is it classified?

Auth Bypass Code Execution Agent API Framework AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0103 - Deploy AI Agent

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system deployment controls

NIST AI RMF

MANAGE 4.1 - Risk treatments, including response and recovery, are documented and monitored

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-55541?

PraisonAI's built-in serve mode exposes two HTTP endpoints, POST /agents and POST /api/v1/agents/{id}/invoke, without any credential check when the app is created via _create_agents_app() or _create_unified_app(), so anyone who can reach the service network-path can create new agents or invoke existing ones as if they were a legitimate operator. This is a low-effort, high-impact bug — CWE-862 Missing Authorization requires no exploit chain, no scanner or PoC exists yet, and it isn't in CISA KEV, but exploitability is trivial for anyone who finds an exposed instance since the fix is simply "add auth," implying none existed at all. Blast radius today looks limited (1 tracked downstream dependent and no severity score yet), but any team that ran `praisonai serve agents` or `praisonai serve unified parse --api-key` reachable from an untrusted network is fully exposed to unauthorized agent creation and invocation, which can translate into data exposure, tool abuse, or resource consumption depending on what tools/credentials the agents hold. Upgrade to praisonai 4.6.58 immediately; until patched, do not expose the serve endpoints to untrusted networks and front them with a reverse proxy enforcing authentication, and audit logs for POST requests to /agents or /api/v1/agents/*/invoke from unexpected sources.

Is CVE-2026-55541 actively exploited?

No confirmed active exploitation of CVE-2026-55541 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-55541?

Patch to praisonai >= 4.6.58, which fixes the missing credential check on both endpoints (see commit 2f9677a and release v4.6.58). Until patched: do not expose `praisonai serve` instances to the public internet or to untrusted internal segments — bind to localhost or a private network only, and place a reverse proxy (e.g. Nginx/Caddy) in front that enforces authentication (API key header, mTLS, or basic auth) before requests reach the app. For detection, review access/proxy logs for unexpected POST requests to `/agents` or `/api/v1/agents/{id}/invoke` from source IPs outside your known automation/CI ranges, and review any agents that were created or invoked outside expected maintenance windows. After patching, verify the new version actually enforces the `--api-key` flag / credential check by testing an unauthenticated request returns 401/403.

What systems are affected by CVE-2026-55541?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, model serving.

What is the CVSS score for CVE-2026-55541?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-agent orchestrationmodel serving

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0103 Deploy AI Agent

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, praisonai serve agents and praisonai serve unified parse --api-key but _create_agents_app() and _create_unified_app() do not install a credential check. Unauthenticated callers can reach POST /agents and POST /api/v1/agents/{id}/invoke. This issue is fixed in version 4.6.58.

Exploitation Scenario

An attacker scans for exposed PraisonAI serve instances (e.g. via internet-wide port/service scanning or by finding a misconfigured internal service) and sends a POST to `/agents` with no credentials to register a new multi-agent team, or targets an existing agent ID via `/api/v1/agents/{id}/invoke` to trigger it directly. If the running agents have tool access — file I/O, internal APIs, cloud credentials, or outbound network calls — the attacker's invocation causes those tools to execute on the attacker's behalf, enabling data exfiltration, internal reconnaissance, or abuse of any connected service, all without ever needing valid credentials for the PraisonAI deployment itself.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-862 Missing Authorization Primary

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.