CVE-2026-61426: PraisonAI insecure defaults expose

CISO Take

PraisonAI, before version 1.7.3, ships with a default configuration that binds its API to all network interfaces, requires no API key, and allows wildcard CORS — meaning any unauthenticated attacker who can reach the host can call GET /api/agents to read agent instructions and system prompts, or POST /api/chat to invoke agents directly. This matters because it is not an obscure edge case but the out-of-the-box behavior: any organization that deployed PraisonAI without hardening the config is exposed with zero attacker skill required, a CVSS 8.6 score, and a public GitHub Security Advisory plus a VulnCheck write-up already available to guide exploitation. There is no CISA KEV listing, EPSS score, or public exploit/Nuclei template yet, so mass automated exploitation has not been confirmed, but the trivial attack complexity and network-facing default mean exposed instances should be treated as compromised the moment they are found by a scanner. Upgrade to PraisonAI 1.7.3 or later immediately, and in the meantime place any PraisonAI deployment behind authentication (reverse proxy with API key/OAuth), bind to localhost or an internal interface only, and restrict CORS to known origins. Detection teams should hunt for unauthenticated GET /api/agents and POST /api/chat requests in access logs, especially from unfamiliar source IPs on internet-facing hosts.

Sources: NVD GitHub Advisory VulnCheck ATLAS

What is the risk?

High risk despite the absence of confirmed active exploitation. The combination of network attack vector, low attack complexity, no privileges required, and no user interaction (CVSS 8.6) means any internet-reachable, unpatched PraisonAI instance is trivially exploitable by an unauthenticated attacker with nothing more than a browser or curl. The confidentiality impact is high (full read of agent instructions/system prompts), while integrity and availability impact are low but non-trivial (unauthenticated invocation of agent behavior via /api/chat). The lack of an EPSS score and CISA KEV listing suggests exploitation has not yet been widely observed or scored, but this is a textbook 'insecure by default' vulnerability class that historically sees opportunistic scanning shortly after public disclosure, particularly once a GitHub Security Advisory and vendor write-up (VulnCheck) are published.

How does the attack unfold?

Discovery

Attacker scans internet-facing hosts and finds a PraisonAI instance running with default settings (all interfaces, no API key, wildcard CORS).

AML.T0049

Reconnaissance via API

Attacker sends an unauthenticated GET request to /api/agents to enumerate agent instructions and system prompts.

AML.T0084

Unauthenticated Invocation

Attacker sends a POST request to /api/chat to invoke one or more agents directly without any credentials.

AML.T0053

Impact

Exposed system prompts and unauthorized agent actions lead to intellectual property leakage and potential abuse of any tools or systems the agents can reach.

AML.T0048.004

Discovery

Attacker scans internet-facing hosts and finds a PraisonAI instance running with default settings (all interfaces, no API key, wildcard CORS).

AML.T0049

Reconnaissance via API

Attacker sends an unauthenticated GET request to /api/agents to enumerate agent instructions and system prompts.

AML.T0084

Unauthenticated Invocation

Attacker sends a POST request to /api/chat to invoke one or more agents directly without any credentials.

AML.T0053

Impact

Exposed system prompts and unauthorized agent actions lead to intellectual property leakage and potential abuse of any tools or systems the agents can reach.

AML.T0048.004

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	—	No patch
1 dependents 74% patched ~0d to patch Full package profile →

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1

8.6 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I Low

A Low

What should I do?

1 step

1) Upgrade PraisonAI to version 1.7.3 or later, which fixes the insecure default configuration. 2) If immediate upgrade isn't possible, do not run PraisonAI bound to 0.0.0.0 or any public interface without placing an authenticating reverse proxy (API key, OAuth, mTLS) in front of it. 3) Restrict CORS to explicit trusted origins rather than wildcard. 4) Apply network-level controls (firewall/security group rules, VPC-only exposure) so the PraisonAI port is not internet-reachable. 5) Audit existing deployments now for accidental public exposure using an external port scan against known PraisonAI ports/paths (/api/agents, /api/chat). 6) For detection, monitor web/proxy logs for unauthenticated GET /api/agents and POST /api/chat requests, especially from unexpected source IPs, and alert on any successful 200 responses to those endpoints without an Authorization header.

How is it classified?

Auth Bypass Data Leakage Data Extraction Agent API AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0056 - Extract LLM System Prompt AML.T0084 - Discover AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.2 - AI system access control

OWASP LLM Top 10

LLM06:2025 - Excessive Agency LLM07:2025 - System Prompt Leakage

Frequently Asked Questions

What is CVE-2026-61426?

PraisonAI, before version 1.7.3, ships with a default configuration that binds its API to all network interfaces, requires no API key, and allows wildcard CORS — meaning any unauthenticated attacker who can reach the host can call GET /api/agents to read agent instructions and system prompts, or POST /api/chat to invoke agents directly. This matters because it is not an obscure edge case but the out-of-the-box behavior: any organization that deployed PraisonAI without hardening the config is exposed with zero attacker skill required, a CVSS 8.6 score, and a public GitHub Security Advisory plus a VulnCheck write-up already available to guide exploitation. There is no CISA KEV listing, EPSS score, or public exploit/Nuclei template yet, so mass automated exploitation has not been confirmed, but the trivial attack complexity and network-facing default mean exposed instances should be treated as compromised the moment they are found by a scanner. Upgrade to PraisonAI 1.7.3 or later immediately, and in the meantime place any PraisonAI deployment behind authentication (reverse proxy with API key/OAuth), bind to localhost or an internal interface only, and restrict CORS to known origins. Detection teams should hunt for unauthenticated GET /api/agents and POST /api/chat requests in access logs, especially from unfamiliar source IPs on internet-facing hosts.

Is CVE-2026-61426 actively exploited?

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

How to fix CVE-2026-61426?

1) Upgrade PraisonAI to version 1.7.3 or later, which fixes the insecure default configuration. 2) If immediate upgrade isn't possible, do not run PraisonAI bound to 0.0.0.0 or any public interface without placing an authenticating reverse proxy (API key, OAuth, mTLS) in front of it. 3) Restrict CORS to explicit trusted origins rather than wildcard. 4) Apply network-level controls (firewall/security group rules, VPC-only exposure) so the PraisonAI port is not internet-reachable. 5) Audit existing deployments now for accidental public exposure using an external port scan against known PraisonAI ports/paths (/api/agents, /api/chat). 6) For detection, monitor web/proxy logs for unauthenticated GET /api/agents and POST /api/chat requests, especially from unexpected source IPs, and alert on any successful 200 responses to those endpoints without an Authorization header.

What systems are affected by CVE-2026-61426?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, API/inference endpoints.

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

CVE-2026-61426 has a CVSS v3.1 base score of 8.6 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksAPI/inference endpoints

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0056 Extract LLM System Prompt

AML.T0084 Discover AI Agent Configuration

Compliance Controls Affected

ISO 42001: A.6.2.2

OWASP LLM Top 10: LLM06:2025, LLM07:2025

What are the technical details?

Original Advisory

PraisonAI before 1.7.3 contains an insecure default configuration that binds to all interfaces with no API key requirement and wildcard CORS. Unauthenticated attackers can call GET /api/agents to read agent instructions and system prompts, or POST /api/chat to invoke agents without authentication.

Exploitation Scenario

An attacker runs internet-wide scanning (e.g., Shodan/Censys or a custom scanner) looking for hosts responding on common PraisonAI ports. Finding an instance running the insecure default configuration, they send an unauthenticated GET request to /api/agents and receive the full list of configured agents along with their system prompts and instructions — giving them a blueprint of the organization's internal automation, business logic, and any embedded secrets or sensitive context. Using that intelligence, the attacker crafts a POST request to /api/chat to directly invoke one or more agents without any credentials, triggering whatever actions those agents are configured to perform (e.g., calling internal tools, querying databases, or interacting with other connected systems), effectively achieving unauthorized use of the organization's AI agent infrastructure with no authentication barrier at all.

Weaknesses (CWE)

CWE-200 Exposure of Sensitive Information to an Unauthorized Actor Primary

CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.