AI Threat AlertCVE-2026-55540: PraisonAI: symlink escape defeats workspace path checks
GHSA-ch89-h4r2-c8f8HIGHCISA: ATTENDPraisonAI's workspace boundary check relied on os.path.abspath() instead of os.path.realpath(), so a symlink planted inside an agent's workspace can point outside it and still pass validation, letting read_file and other code tools reach arbitrary files on the host. This matters for anyone running PraisonAI agents with filesystem tools enabled against workspaces that ingest external content — uploaded files, cloned repos, shared folders — since a single crafted symlink can leak credentials, config, or source code the sandbox was supposed to contain. There is no known public exploit, no CISA KEV listing, and EPSS data is unavailable, and the package shows only 1 tracked downstream dependent, so exploitation-in-the-wild pressure is currently low; the CVSS 7.1 (AC:H, UI:R) also means it needs a specific setup and user interaction rather than a trivial remote hit. Upgrade to praisonai 4.6.58 or later, and until patched, audit any workspace directories for unexpected symlinks and avoid granting file-tool access to workspaces populated with untrusted or externally-sourced content.
What is the risk?
High-impact but constrained-likelihood vulnerability. Confidentiality and integrity impact are both High (arbitrary file read/write outside the sandbox), but Attack Complexity is High and User Interaction is Required, meaning an attacker needs a specific precondition (ability to place a symlink in the agent's workspace) plus some action that triggers the agent's file tool against that path. No KEV listing, no EPSS score, and no public PoC/scanner coverage lower near-term exploitation probability, and the tracked downstream footprint (1 dependent) limits blast radius today. Risk rises sharply for any deployment where the workspace ingests external or multi-tenant content (uploaded files, cloned repos, shared drives) combined with file-reading agent tools.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| PraisonAI | pip | < 4.6.58 | 4.6.58 |
Do you use PraisonAI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 stepUpgrade to praisonai >= 4.6.58, which fixes is_path_within_directory() to use os.path.realpath() so symlink targets are resolved before the boundary check. Until upgraded, audit existing workspace directories for symlinks pointing outside the sandbox root and remove them; avoid mounting or syncing workspaces from untrusted sources (uploads, external repos) into agent-accessible directories; restrict agent file tools to workspaces on filesystems/mounts that disallow symlink creation where feasible (e.g., noexec/nosymfollow mount options or containerized workspaces with restricted mount points). For detection, monitor read_file/write tool invocations for paths that resolve (via realpath) outside the configured workspace root, and log/alert on symlink creation events inside agent workspace directories.
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-55540?
PraisonAI's workspace boundary check relied on os.path.abspath() instead of os.path.realpath(), so a symlink planted inside an agent's workspace can point outside it and still pass validation, letting read_file and other code tools reach arbitrary files on the host. This matters for anyone running PraisonAI agents with filesystem tools enabled against workspaces that ingest external content — uploaded files, cloned repos, shared folders — since a single crafted symlink can leak credentials, config, or source code the sandbox was supposed to contain. There is no known public exploit, no CISA KEV listing, and EPSS data is unavailable, and the package shows only 1 tracked downstream dependent, so exploitation-in-the-wild pressure is currently low; the CVSS 7.1 (AC:H, UI:R) also means it needs a specific setup and user interaction rather than a trivial remote hit. Upgrade to praisonai 4.6.58 or later, and until patched, audit any workspace directories for unexpected symlinks and avoid granting file-tool access to workspaces populated with untrusted or externally-sourced content.
Is CVE-2026-55540 actively exploited?
No confirmed active exploitation of CVE-2026-55540 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-55540?
Upgrade to praisonai >= 4.6.58, which fixes is_path_within_directory() to use os.path.realpath() so symlink targets are resolved before the boundary check. Until upgraded, audit existing workspace directories for symlinks pointing outside the sandbox root and remove them; avoid mounting or syncing workspaces from untrusted sources (uploads, external repos) into agent-accessible directories; restrict agent file tools to workspaces on filesystems/mounts that disallow symlink creation where feasible (e.g., noexec/nosymfollow mount options or containerized workspaces with restricted mount points). For detection, monitor read_file/write tool invocations for paths that resolve (via realpath) outside the configured workspace root, and log/alert on symlink creation events inside agent workspace directories.
What systems are affected by CVE-2026-55540?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, agent file-system tools, RAG ingestion pipelines.
What is the CVSS score for CVE-2026-55540?
CVE-2026-55540 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.39%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0037Data from Local SystemAML.T0053AI Agent Tool InvocationAML.T0086Exfiltration via AI Agent Tool InvocationCompliance Controls Affected
What are the technical details?
Original Advisory
PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, is_path_within_directory() uses os.path.abspath() rather than os.path.realpath() for the workspace boundary. A symlink inside workspace can point outside and still pass the check, allowing read_file and other code tools to access files outside the configured workspace. This issue is fixed in version 4.6.58.
Exploitation Scenario
An attacker with the ability to place a file into a PraisonAI agent's workspace — for example via a file-upload feature, a shared workspace, or a cloned repository the agent is asked to process — plants a symlink named to look benign (e.g., 'notes.txt') that actually points to a sensitive path like a credentials file, environment config, or SSH key outside the sandbox. The attacker then gets the agent to interact with that file, either by directly instructing it (if they have some access) or via a crafted document/prompt that induces the agent to invoke its read_file tool on the symlinked path. Because is_path_within_directory() only normalizes the path with abspath() rather than resolving the symlink with realpath(), the check passes, the tool follows the symlink, and the contents of the out-of-sandbox file are read back into the agent's context — and from there potentially exposed in the agent's output, logs, or to the attacker directly.
Weaknesses (CWE)
CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')PrimaryCWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')PrimaryCWE-22Improper 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.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:LReferences
Timeline
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