PraisonAI vulnerable to unauthenticated arbitrary file read via MCP workflow.show, workflow.validate, deploy.validate
Summary
The fix for GHSA-9mqq-jqxf-grvw / CVE-2026-44336 is incomplete. The original advisory description named four vulnerable handlers in mcp_server/adapters/cli_tools.py:
> "registers four file-handling tools by default, praisonai.rules.create, praisonai.rules.show, praisonai.rules.delete, and praisonai.workflow.show. Each accepts a path or filename string from MCP tools/call arguments… with no containment check."
Commit 68cc9427 ("fix(security): harden MCP rules path handling…") added a _resolve_rule_path() helper and applied it to rules.create, rules.show, and rules.delete. workflow.show was left unchanged. Two adjacent handlers in the same file have the same pattern, workflow.validate and deploy.validate. Neither was mentioned in the original advisory. Both remain unchanged.
The original advisory also identified the dispatcher (server.py:281-298) as a root cause. It accepts unvalidated **kwargs from params["arguments"] with no enforcement against the tool's declared input_schema. That code is unchanged in HEAD as of commit 42221210.
Result: A single unauthenticated MCP tools/call to praisonai.workflow.show returns the contents of any file the host user can read: /etc/passwd, ~/.ssh/id_rsa, ~/.aws/credentials, or any project .env.
Affected functionality
src/praisonai/praisonai/mcp_server/adapters/cli_tools.py:
| Lines | Tool | Bug |
|-------|------|-----|
| 63-73 | praisonai.workflow.show | Returns the full contents of any file the host user can read |
| 42-61 | praisonai.workflow.validate | Reads any path; YAML parser error messages leak file existence + content fragments |
| 415-432 | praisonai.deploy.validate | Same pattern as workflow.validate. The config_path="deploy.yaml" default does not constrain the input. |
src/praisonai/praisonai/mcp_server/server.py:281-298, _handle_tools_call:
```python
async def _handle_tools_call(self, params: Dict[str, Any]) -> Dict[str, Any]:
tool_name = params.get("name")
arguments = params.get("arguments", {})
...
tool = self._tool_registry.get(tool_name)
...
if asyncio.iscoroutinefunction(tool.handler):
result = await tool.handler(**arguments) # ← no schema enforcement
else:
result = tool.handler(**arguments)
```
Any JSON arguments the MCP client sends become a **kwargs call to the handler. The original advisory pointed at this code path as the root cause. The May 3 patch did not change it.
Default deployment is exposed
src/praisonai/praisonai/mcp_server/transports/http_stream.py:38-91:
host defaults to 127.0.0.1, which is still reachable from any local process or container neighbour on loopback.api_key defaults to None. The auth check at http_stream.py:192-198 is gated on if self.api_key:, so it is skipped when no key is configured. There is no env var or config switch that turns auth on by default.- The same handlers are also reachable on the stdio transport, which is the exploitation model the original advisory was written around (Claude Desktop, Cursor, Continue.dev, Claude Code).
Other file-read sinks reachable via the same dispatcher
These were not named in the original advisory. They confirm the bug is dispatcher-wide and not limited to cli_tools.py:
mcp_server/adapters/capabilities.py:19-28, praisonai.audio.transcribe(file_path). Opens any host file and ships it to OpenAI Whisper.mcp_server/adapters/extended_capabilities.py:47-62, praisonai.files.create(file_path). Uploads any host file to OpenAI Files. A follow-up call to praisonai.files.content(file_id) (extended_capabilities.py:103-113) returns the bytes.mcp_server/adapters/extended_capabilities.py:243-258, praisonai.ocr_extract(image_path). Opens any image, returns OCR text.
The three handlers in cli_tools.py are the most direct primitives, since they echo the file content back without an OpenAI round-trip.
Proof of Concept
Layout
```
PraisonAI/
└── poc/
├── start_mcp_server.sh ← starts the real MCP server
├── run_mcp_poc_video.sh ← runs the attack with curl
├── venv/
└── output/
├── mcp_server_run.log
├── mcp_attacker_run.log
└── synthetic_credentials.txt (PoC-only fake creds)
```
[start_mcp_server.sh](https://github.com/user-attachments/files/27569524/start_mcp_server.sh)
[run_mcp_poc_video.sh](https://github.com/user-attachments/files/27569525/run_mcp_poc_video.sh)
The server starter runs the real MCPServer class with register_cli_tools(), same code path praisonai mcp serve --transport http-stream uses. No mocks.
How to reproduce
Terminal 1, start the server:
```bash
cd PraisonAI
bash poc/start_mcp_server.sh
```
Boots MCPServer on 127.0.0.1:8766/mcp with no auth, matchin
