Description

PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODE_TOOLS wrappers keep _workspace_root as None and pass workspace=None to read_file, search_replace, and apply_diff helpers that enforce path containment only for a truthy workspace. An application that exposes code_read_file, code_search_replace, or code_apply_diff before set_workspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-09-14T16:17:12.977Z",
  "pubdate": "2026-09-14T16:17:12.977Z",
  "executiveSummary": "PraisonAI versions prior to 4.6.59 are susceptible to a Path Traversal vulnerability arising from improper input validation in its CODE_TOOLS module.\nThe vulnerability occurs because workspace enforcement mechanisms fail when the _workspace_root attribute is not explicitly initialized.\nIf an application utilizes code_read_file, code_search_replace, or code_apply_diff helpers before a workspace is defined, the lack of a truthy workspace object bypasses the path containment logic.\nAn attacker capable of influencing prompts can exploit this oversight to read from or modify arbitrary files on the host filesystem that reside outside the intended project directory.\nThe risk is significant as it permits unauthorized file system access, potentially leading to information disclosure or the injection of malicious code into system or application files.\nSuccessful exploitation requires the application to expose code tools prior to the configuration of a workspace, making early-lifecycle state management a critical exploitation factor.",
  "technicalDetails": "The vulnerability resides in the CODE_TOOLS wrappers within PraisonAI, specifically affecting the read_file, search_replace, and apply_diff utility functions. These functions are designed to maintain file system isolation by enforcing path containment, ensuring that operations are restricted to a defined project workspace. The security logic relies on the existence of a truthy workspace object to trigger these containment checks.\nIn versions prior to 4.6.59, the _workspace_root attribute is initialized as None by default. When these code tool helpers are invoked before the application has explicitly executed a set_workspace command, the workspace parameter remains None. Because the enforcement logic explicitly checks for a truthy workspace before applying path containment filters, these checks are effectively bypassed when the workspace is uninitialized.\nThe attack flow begins when a PraisonAI-based application exposes code_read_file, code_search_replace, or code_apply_diff tools to a user-controlled prompt interface prior to the system's workspace configuration phase. An attacker can supply crafted file paths—such as those utilizing directory traversal sequences (e.g., ../../../etc/passwd)—within their prompts. Since the defensive wrappers fail to validate these paths due to the missing workspace context, the underlying filesystem calls execute the requested operations on paths outside the intended sandbox.\nThis allows for arbitrary file read (Information Disclosure), arbitrary file overwrite, and potentially Remote Code Execution (RCE) if an attacker modifies sensitive configuration files, SSH keys, or executable scripts on the host system. The lack of an initialized workspace essentially disables the security boundary, transforming a restricted toolset into a general-purpose filesystem manipulation interface. The vulnerability is explicitly fixed in version 4.6.59 by ensuring that workspace constraints are correctly validated or enforced even when the workspace root is not explicitly defined or is in a default state.\nExploitation is strictly contingent upon the application design pattern where code tools are accessible or usable prior to formal workspace initialization. There is no requirement for external network exposure, as the impact is local to the filesystem of the server hosting the PraisonAI instance."
}