CVE-2026-57127: PraisonAI: auth middleware fails open, exposes agents

CRITICAL
Published September 14, 2026
CISO Take

PraisonAI's recipe serve component ships an API-key or JWT auth middleware that is supposed to gate access to agent execution, but if the operator forgets to set PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET (or the recipe's own auth value), the middleware silently forwards the request instead of rejecting it — a textbook fail-open bug (CWE-306, CVSS 9.8, network, no privileges, no user interaction). This matters because operators who explicitly enabled authentication will reasonably assume they're protected, when in fact any unauthenticated client can reach recipe execution, input and output surfaces and trigger whatever tools the agent is wired to — file systems, internal APIs, other services. There's no CISA KEV listing, no public exploit, and no Nuclei template today, and EPSS data isn't available yet, so this is not (yet) a mass-exploited bug, but the flaw is trivial to find and trigger once an attacker knows to test for missing env vars, and multi-agent frameworks are increasingly internet-exposed. Patch to PraisonAI 4.6.58 immediately, and before trusting any deployment, actively verify that unauthenticated requests are rejected (don't just confirm the env vars are set — confirm the middleware actually enforces them) and rotate any keys/secrets that may have been exposed during the window the instance was effectively open.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Critical on paper (CVSS 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and critical in practice for any operator who believed auth was enforced: the vulnerability is a silent fail-open, meaning security posture degrades without any error or warning. Exploitability is low-effort — no special AI/ML knowledge required, just an HTTP request without credentials against a misconfigured (but 'auth-enabled') instance. Exposure is currently unclear (no CISA KEV, no known public exploit, EPSS unavailable), which lowers near-term mass-exploitation likelihood, but the simplicity of the bug and the fact that the failure mode is invisible to operators until tested makes real-world exposure hard to estimate from telemetry alone — treat as high risk until instances are confirmed patched or verified.

How does the attack unfold?

Discovery
Attacker locates an internet-facing PraisonAI recipe serve instance configured with api-key or JWT authentication.
AML.T0006
Authentication bypass
Attacker sends a request without credentials; the middleware forwards it anyway because PRAISONAI_API_KEY/PRAISONAI_JWT_SECRET (or the recipe's own value) was never configured.
AML.T0049
Tool invocation
With unauthenticated access to recipe execution, input, and output surfaces, the attacker triggers connected tools the agent has access to.
AML.T0053
Impact
Attacker exfiltrates data or abuses tool access for further compromise, resulting in full loss of confidentiality, integrity, and availability as reflected by the 9.8 CVSS score.
AML.T0086

What systems are affected?

Package Ecosystem Vulnerable Range Patched
PraisonAI pip No patch

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1
9.8 / 10
EPSS
0.9%
chance of exploitation in 30 days
Higher than 58% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Unchanged
C High
I High
A High

What should I do?

1 step
  1. 1) Upgrade to PraisonAI 4.6.58 or later immediately — this is the only complete fix. 2) Before and after patching, actively test that an unauthenticated request against the recipe serve endpoint is rejected (do not just confirm the env var is set in config — send a live request without credentials and confirm a 401/403). 3) Audit PRAISONAI_API_KEY and PRAISONAI_JWT_SECRET configuration across all environments (dev/staging/prod) for missing or empty values. 4) Rotate API keys/JWT secrets for any instance that may have been exposed prior to patching. 5) Review access/application logs for recipe execution requests lacking valid auth headers during the exposure window. 6) As defense-in-depth, place PraisonAI serve endpoints behind a network-level control (reverse proxy auth, VPN, allowlist) rather than relying solely on application-layer auth. 7) Inventory which tools each exposed recipe is connected to, to scope potential blast radius if the instance was reachable pre-patch.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.9.3 - AI system operation and monitoring
OWASP LLM Top 10
LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-57127?

PraisonAI's recipe serve component ships an API-key or JWT auth middleware that is supposed to gate access to agent execution, but if the operator forgets to set PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET (or the recipe's own auth value), the middleware silently forwards the request instead of rejecting it — a textbook fail-open bug (CWE-306, CVSS 9.8, network, no privileges, no user interaction). This matters because operators who explicitly enabled authentication will reasonably assume they're protected, when in fact any unauthenticated client can reach recipe execution, input and output surfaces and trigger whatever tools the agent is wired to — file systems, internal APIs, other services. There's no CISA KEV listing, no public exploit, and no Nuclei template today, and EPSS data isn't available yet, so this is not (yet) a mass-exploited bug, but the flaw is trivial to find and trigger once an attacker knows to test for missing env vars, and multi-agent frameworks are increasingly internet-exposed. Patch to PraisonAI 4.6.58 immediately, and before trusting any deployment, actively verify that unauthenticated requests are rejected (don't just confirm the env vars are set — confirm the middleware actually enforces them) and rotate any keys/secrets that may have been exposed during the window the instance was effectively open.

Is CVE-2026-57127 actively exploited?

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

How to fix CVE-2026-57127?

1) Upgrade to PraisonAI 4.6.58 or later immediately — this is the only complete fix. 2) Before and after patching, actively test that an unauthenticated request against the recipe serve endpoint is rejected (do not just confirm the env var is set in config — send a live request without credentials and confirm a 401/403). 3) Audit PRAISONAI_API_KEY and PRAISONAI_JWT_SECRET configuration across all environments (dev/staging/prod) for missing or empty values. 4) Rotate API keys/JWT secrets for any instance that may have been exposed prior to patching. 5) Review access/application logs for recipe execution requests lacking valid auth headers during the exposure window. 6) As defense-in-depth, place PraisonAI serve endpoints behind a network-level control (reverse proxy auth, VPN, allowlist) rather than relying solely on application-layer auth. 7) Inventory which tools each exposed recipe is connected to, to scope potential blast radius if the instance was reachable pre-patch.

What systems are affected by CVE-2026-57127?

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

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

CVE-2026-57127 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.90%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-agent orchestrationAI agent tool/API serving

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application
AML.T0053 AI Agent Tool Invocation
AML.T0084.001 Tool Definitions

Compliance Controls Affected

ISO 42001: A.9.3
OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

PraisonAI is a multi-agent teams system. Prior to 4.6.58, recipe serve installs APIKeyAuthMiddleware or JWTAuthMiddleware when an operator selects api-key or JWT authentication, but each middleware forwards requests when PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET and the corresponding recipe value are absent. Unauthenticated clients can then reach recipe execution, input, and output surfaces and may trigger connected tools despite the operator explicitly enabling authentication. This issue is fixed in 4.6.58.

Exploitation Scenario

An attacker discovers an internet-facing PraisonAI 'recipe serve' endpoint (via scanning, Shodan-style discovery, or targeting a known company deployment) that has authentication nominally enabled. The attacker sends a request to the recipe execution endpoint without any Authorization header or API key. Because the operator never set PRAISONAI_API_KEY (or PRAISONAI_JWT_SECRET) in the environment, the auth middleware — instead of rejecting the request — forwards it as if authenticated. The attacker now has full access to trigger the agent recipe, submit arbitrary inputs, read outputs, and invoke any connected tools (e.g., a tool that reads internal files, calls an internal API, or writes to a database), achieving data exfiltration or downstream system compromise without ever needing valid credentials.

Weaknesses (CWE)

CWE-1188 — Initialization of a Resource with an Insecure Default: The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Timeline

Published
September 14, 2026
Last Modified
September 16, 2026
First Seen
September 14, 2026

Related Vulnerabilities