CVE-2026-57145: PraisonAI path traversal lets

CISO Take

PraisonAI's multiedit tool takes the filepath the LLM decides to use and hands it straight to open() for reading and writing, with no traversal rejection, symlink resolution, workspace boundary, or protected-path check — so any agent that can be steered by untrusted input can escape its intended sandbox. This is a network-exploitable, no-auth, no-user-interaction flaw (CVSS 9.1) in a widely deployed multi-agent framework, and it doesn't require a novel AI attack technique — just a prompt-injected instruction to point the edit/diff tool at a path like a credentials file or an application entrypoint. There's no evidence of a public exploit, Nuclei template, or CISA KEV listing yet, and EPSS data isn't available, so this looks pre-weaponization rather than actively exploited — but the low complexity and high confidentiality/integrity impact make it a prime target once someone builds a proof of concept. Any team running PraisonAI agents against untrusted content (tickets, web pages, RAG documents, emails) should treat this as urgent: upgrade to 4.6.62 immediately, and in the meantime audit which files/directories the agent process can reach and alert on multiedit calls that touch paths outside the expected project root.

Sources: NVD GitHub Advisory CISA KEV ATLAS

What is the risk?

High risk despite the absence of confirmed in-the-wild exploitation. The CVSS 9.1 score reflects a network-reachable, unauthenticated, low-complexity path to high-confidentiality/high-integrity impact — but the real trigger condition is getting the agent to process attacker-influenced content (a ticket, document, retrieved web page, or chained tool output) that steers the multiedit call. That's a low bar in any deployment where PraisonAI agents ingest external or semi-trusted data, which is the common case for autonomous agent teams. Because there's no traversal rejection, symlink resolution, or workspace boundary at all (not a partial bypass — a total absence of controls), any successful injection reliably yields file read or write outside the intended sandbox. The main mitigating factor today is that no public exploit or scanner template exists, so exploitation currently requires bespoke prompt engineering rather than a drop-in payload.

How does the attack unfold?

Injection

Attacker embeds a malicious instruction in content the agent will ingest (a ticket, document, web page, or repo file) to steer its next tool call.

AML.T0051.001

Tool invocation

The agent calls the multiedit tool with an attacker-influenced filepath (e.g. containing `../` or pointing to a symlink) that is passed straight to open() with no boundary checks.

AML.T0053

Data exposure

The tool reads a sensitive file outside the workspace and returns its contents via the edit/diff output, leaking secrets to the attacker.

AML.T0037

Persistence/tampering

Alternatively, the tool writes attacker-controlled content to a file the process can access, planting a backdoor or corrupting application behavior.

AML.T0081

Injection

Attacker embeds a malicious instruction in content the agent will ingest (a ticket, document, web page, or repo file) to steer its next tool call.

AML.T0051.001

Tool invocation

The agent calls the multiedit tool with an attacker-influenced filepath (e.g. containing `../` or pointing to a symlink) that is passed straight to open() with no boundary checks.

AML.T0053

Data exposure

The tool reads a sensitive file outside the workspace and returns its contents via the edit/diff output, leaking secrets to the attacker.

AML.T0037

Persistence/tampering

Alternatively, the tool writes attacker-controlled content to a file the process can access, planting a backdoor or corrupting application behavior.

AML.T0081

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.1 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 30% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A None

What should I do?

1 step

Upgrade PraisonAI to 4.6.62 or later, where the filepath handling in multiedit.py adds traversal rejection, symlink resolution, and workspace boundary enforcement. Until patched, run agents with the least-privilege filesystem access possible (a dedicated low-privilege service account, chroot/container jail, or read-only mounts for anything outside the working directory), and explicitly deny access to sensitive paths (.env, SSH keys, cloud credential files, system config) at the OS/container level rather than relying on the application. Treat any content an agent ingests from outside your control (tickets, web content, RAG documents, other agents' outputs) as untrusted input that could contain injected tool instructions. For detection, log and alert on multiedit/file-tool invocations whose resolved path (after symlink/.. resolution) falls outside the expected project root, and monitor for unexpected reads of credential files or writes to executable/config paths from the agent process.

How is it classified?

Prompt Injection Data Leakage Code Execution Agent Plugin AML.T0037 - Data from Local System AML.T0051.001 - Indirect AML.T0053 - AI Agent Tool Invocation AML.T0081 - Modify AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluated and documented

OWASP LLM Top 10

LLM01:2025 - Prompt Injection LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-57145?

PraisonAI's multiedit tool takes the filepath the LLM decides to use and hands it straight to open() for reading and writing, with no traversal rejection, symlink resolution, workspace boundary, or protected-path check — so any agent that can be steered by untrusted input can escape its intended sandbox. This is a network-exploitable, no-auth, no-user-interaction flaw (CVSS 9.1) in a widely deployed multi-agent framework, and it doesn't require a novel AI attack technique — just a prompt-injected instruction to point the edit/diff tool at a path like a credentials file or an application entrypoint. There's no evidence of a public exploit, Nuclei template, or CISA KEV listing yet, and EPSS data isn't available, so this looks pre-weaponization rather than actively exploited — but the low complexity and high confidentiality/integrity impact make it a prime target once someone builds a proof of concept. Any team running PraisonAI agents against untrusted content (tickets, web pages, RAG documents, emails) should treat this as urgent: upgrade to 4.6.62 immediately, and in the meantime audit which files/directories the agent process can reach and alert on multiedit calls that touch paths outside the expected project root.

Is CVE-2026-57145 actively exploited?

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

How to fix CVE-2026-57145?

Upgrade PraisonAI to 4.6.62 or later, where the filepath handling in multiedit.py adds traversal rejection, symlink resolution, and workspace boundary enforcement. Until patched, run agents with the least-privilege filesystem access possible (a dedicated low-privilege service account, chroot/container jail, or read-only mounts for anything outside the working directory), and explicitly deny access to sensitive paths (.env, SSH keys, cloud credential files, system config) at the OS/container level rather than relying on the application. Treat any content an agent ingests from outside your control (tickets, web content, RAG documents, other agents' outputs) as untrusted input that could contain injected tool instructions. For detection, log and alert on multiedit/file-tool invocations whose resolved path (after symlink/`..` resolution) falls outside the expected project root, and monitor for unexpected reads of credential files or writes to executable/config paths from the agent process.

What systems are affected by CVE-2026-57145?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, coding/dev-tool agents.

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

CVE-2026-57145 has a CVSS v3.1 base score of 9.1 (CRITICAL). The EPSS exploitation probability is 0.36%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-agent orchestrationcoding/dev-tool agents

MITRE ATLAS Techniques

AML.T0037 Data from Local System

AML.T0051.001 Indirect

AML.T0053 AI Agent Tool Invocation

AML.T0081 Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM01:2025, LLM02:2025

What are the technical details?

Original Advisory

PraisonAI is a multi-agent teams system. Prior to 4.6.62, src/praisonai/praisonai/tools/multiedit.py passes the LLM-controlled filepath parameter directly to open for reading and writing without traversal rejection, symlink resolution, a workspace boundary, or protected-path checks. Prompt-influenced agents can read files through edit and diff behavior or overwrite files accessible to the process, exposing secrets and enabling persistence or application tampering. This issue is fixed in 4.6.62.

Exploitation Scenario

An attacker plants a malicious instruction inside content they know a PraisonAI agent will eventually process — for example a support ticket, a web page fetched by a research agent, or a file committed to a repo the agent is asked to review. That instruction is a classic indirect prompt injection: it tells the agent to 'fix a bug' by editing a path like `../../.env` or `/home/app/.ssh/id_rsa`, or to 'clean up' by writing attacker-controlled content to a cron script or application config file. Because multiedit.py never validates that the resolved path stays inside the workspace, the agent dutifully opens the file, and the resulting diff or edit output leaks secrets back to the attacker (via the agent's response) or silently corrupts a file the attacker chose for persistence — e.g., planting a backdoored script that runs on the next deploy or scheduled job.

Weaknesses (CWE)

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Primary CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[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.