Overview
The PraisonAI system is susceptible to a critical vulnerability that allows for the unauthorized reading of arbitrary files. This is made possible through the MCP (Machine Learning Model Control) workflow, specifically through the 'workflow.show', 'workflow.validate', and 'deploy.validate' tools. These tools, part of the PraisonAI's MCP server, do not properly validate or contain file paths, leading to a situation where an attacker can potentially read any file that the host user can access.
Technical Details
The vulnerability is rooted in the way PraisonAI handles file paths within its MCP server. The 'workflow.show', 'workflow.validate', and 'deploy.validate' tools are registered with default settings that do not include proper path validation or containment. This oversight allows an attacker to manipulate file paths in such a way that they can read files outside of the intended directories.
The dispatcher in `mcp_server/server.py` accepts unvalidated `**kwargs` from `params["arguments"]` without enforcing the tool's declared `input_schema`. This lack of validation is a critical part of the vulnerability, as it enables the exploitation of multiple handlers beyond just those in `cli_tools.py`.
Impact Analysis
The impact of this vulnerability is significant, with a confidentiality impact rated as High. An attacker can exploit this vulnerability to read any file that the PraisonAI user can read, without needing authentication. Typical targets for such exploitation include host SSH keys, cloud credentials, API tokens, project `.env` files, and other sensitive information.
The default configuration of PraisonAI, with `api_key=None`, leaves the system exposed to such attacks. The exploitation model, as described in the original advisory, still applies, where an MCP-connected LLM can be steered into issuing `tools/call` commands and returning responses without requiring operator intervention.
Mitigation
There are two primary methods to mitigate this vulnerability:
1. **Enforce `tool.input_schema` in the dispatcher**: Validate `arguments` against the registered schema before calling `tool.handler(**arguments)`. This approach covers not just the affected tools but also any handler added later, providing a comprehensive fix.
2. **Per-handler containment**: Implement path containment helpers similar to `_resolve_rule_path()` for each affected handler. This involves restricting file paths to allowed roots, such as a workflow root for `workflow_show` and `workflow_validate`, and a deploy-config root or explicit allowlist for `deploy_validate`.
By implementing these mitigations, the risk associated with this vulnerability can be significantly reduced, protecting sensitive information from unauthorized access.