AI Threat AlertCVE-2026-57113: PraisonAI: path traversal in template cache deletes dirs
HIGHPraisonAI's template loader, in versions 2.6.0 up to 4.6.58, builds its cache path from an unvalidated GitHub template ref. A crafted ref such as '../../../..' escapes the cache root, so the loader writes metadata outside it and, once the normal cache hierarchy exists, runs shutil.rmtree on an attacker-chosen directory. Exploitation needs a user or agent to load a malicious template URI, but the attack is network-reachable, low complexity and needs no privileges (CVSS 8.1). It could erase the home directory, agent configs or mounted data volumes. There is no EPSS score, no KEV listing, no public exploit and no Nuclei template, so exploitation is not observed today. Dependent counts are unknown, so exposure is hard to size. Upgrade to PraisonAI 4.6.59 or later, and until then do not load templates from untrusted sources or run the loader under a least-privilege account.
What is the risk?
High severity (CVSS 8.1) with integrity and availability impact and no confidentiality impact. The weakness is easy to exploit (low complexity, no privileges), but it needs user interaction because the victim must load a crafted template URI. There is no KEV listing, no public exploit, no Nuclei template and no EPSS data, so the near-term likelihood of mass exploitation looks moderate. The real risk is highest where PraisonAI runs with broad filesystem permissions, such as developer workstations, CI runners and agent hosts with mounted data volumes. Package risk data is unavailable, so the exposure estimate has low confidence.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| PraisonAI | pip | — | No patch |
Do you use PraisonAI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade PraisonAI to 4.6.59 or later (affected range: 2.6.0 to before 4.6.59). 2) Until patched, load templates only from trusted, pinned repositories and reject refs containing '..', path separators or absolute paths. 3) Run PraisonAI under a dedicated low-privilege account or container with a read-only root filesystem and only the required writable mounts. 4) Back up data directories, agent configs and ~/.praison regularly so that deletion is recoverable. 5) Detection: audit logs and CI configs for template URIs with '../' in the ref, monitor for unexpected deletions or .cache_meta.json files outside ~/.praison/cache/templates, and track the GHSA-f44v-7qgw-9gh9 advisory.
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-57113?
PraisonAI's template loader, in versions 2.6.0 up to 4.6.58, builds its cache path from an unvalidated GitHub template ref. A crafted ref such as '../../../..' escapes the cache root, so the loader writes metadata outside it and, once the normal cache hierarchy exists, runs shutil.rmtree on an attacker-chosen directory. Exploitation needs a user or agent to load a malicious template URI, but the attack is network-reachable, low complexity and needs no privileges (CVSS 8.1). It could erase the home directory, agent configs or mounted data volumes. There is no EPSS score, no KEV listing, no public exploit and no Nuclei template, so exploitation is not observed today. Dependent counts are unknown, so exposure is hard to size. Upgrade to PraisonAI 4.6.59 or later, and until then do not load templates from untrusted sources or run the loader under a least-privilege account.
Is CVE-2026-57113 actively exploited?
No confirmed active exploitation of CVE-2026-57113 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-57113?
1) Upgrade PraisonAI to 4.6.59 or later (affected range: 2.6.0 to before 4.6.59). 2) Until patched, load templates only from trusted, pinned repositories and reject refs containing '..', path separators or absolute paths. 3) Run PraisonAI under a dedicated low-privilege account or container with a read-only root filesystem and only the required writable mounts. 4) Back up data directories, agent configs and ~/.praison regularly so that deletion is recoverable. 5) Detection: audit logs and CI configs for template URIs with '../' in the ref, monitor for unexpected deletions or .cache_meta.json files outside ~/.praison/cache/templates, and track the GHSA-f44v-7qgw-9gh9 advisory.
What systems are affected by CVE-2026-57113?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, CI/CD pipelines running agents, template-driven agent deployments.
What is the CVSS score for CVE-2026-57113?
CVE-2026-57113 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.40%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.005AI Agent ToolAML.T0011.003Malicious LinkAML.T0101Data Destruction via AI Agent Tool InvocationCompliance Controls Affected
What are the technical details?
Original Advisory
PraisonAI is a multi-agent teams system. From version 2.6.0 to before version 4.6.59, PraisonAI's template loader accepts GitHub template URIs with refs, for example github:owner/repo/template@v1.0.0. The resolver stores the user-controlled template path and ref verbatim, and the cache layer later joins those values into ~/.praison/cache/templates/github/<owner>/<repo>/<template>/<ref> without normalizing each segment or checking that the final path remains inside the template cache root. A crafted ref such as ../../../../../../outside-delete-target therefore escapes the cache directory. The first load can write .cache_meta.json outside the cache. If the normal cache hierarchy for the same owner/repo/template has already been created, the same path reaches shutil.rmtree(cache_path) and removes an attacker-selected outside directory before replacing it with cache metadata. This issue has been patched in version 4.6.59.
Exploitation Scenario
An attacker publishes a template reference or documentation snippet, for example 'github:victim-org/repo/template@../../../../../../home/user/data'. The first load by a developer or an automated agent pipeline writes .cache_meta.json at the traversal path and confirms the escape. A second load, after the normal cache directory for that owner/repo/template exists, makes the cache layer call shutil.rmtree on the attacker-chosen directory, such as the user's project data, agent configuration or a mounted volume, and replaces it with cache metadata. The attacker can spread the lure through shared agent configs, tutorials or pull requests that change template URIs.
Weaknesses (CWE)
CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')PrimaryCWE-73External Control of File Name or PathPrimaryCWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')CWE-73External Control of File Name or PathCWE-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.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:HTimeline
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