PraisonAI's knowledge-store backends for SQL and CQL databases interpolate unvalidated collection and name parameters directly into query strings, leading to potential SQL and CQL injection vulnerabilities. This affects the pgvector, Cassandra, and SingleStore vector backends. The issue arises because these backends do not validate or quote collection names before using them in dynamic SQL/CQL statements. A validation function exists elsewhere in the codebase but is not applied here. Versions from 2.4.1 up to but not including 4.6.34 are affected. A fix is available in version 4.6.34.
PraisonAI ships a legacy Flask API server with authentication disabled by default, allowing any unauthenticated caller who can reach the server to access sensitive endpoints such as /agents and /chat. This enables triggering configured workflows without providing any authentication token. The vulnerable server binds to 0.0.0.0:8080 by default, exposing it to network access. Although newer commands provide safer defaults, the legacy server and generated sample deployment remain insecure. This issue affects versions from 2.5.6 up to but not including 4.6.34. A fix is available in version 4.6.34.
PraisonAI is a multi-agent teams system. Prior to version 4.6.34, PraisonAI's MCP (Model Context Protocol) server (praisonai mcp serve) 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 and joins it onto ~/.praison/rules/ (or, for workflow.show, accepts an absolute path) with no containment check. The JSON-RPC dispatcher passes params["arguments"] blind to each handler via **kwargs without validating against the advertised input schema. By setting rule_name="../../<some-path>" an attacker walks out of the rules directory and writes any file the running user can write. Dropping a Python .pth file into the user site-packages directory escalates this primitive to arbitrary code execution in any subsequent Python process the user spawns — the next praisonai CLI invocation, an IDE script run, the user's python REPL, or any background Python service. This issue has been patched in version 4.6.34.
PraisonAI is a multi-agent teams system. Prior to praisonai version 4.6.9 and praisonaiagents version 1.6.9, the fix for CVE-2026-40315 added input validation to SQLiteConversationStore only. Nine sibling backends — MySQL, PostgreSQL, async SQLite/MySQL/PostgreSQL, Turso, SingleStore, Supabase, SurrealDB — pass table_prefix straight into f-string SQL. Same root cause, same code pattern, same exploitation.52 unvalidated injection points across the codebase.postgres.py additionally accepts an unvalidated schema parameter used directly in DDL. This issue has been patched in praisonai version 4.6.9 and praisonaiagents version 1.6.9.
PraisonAI versions 4.5.138 and earlier are vulnerable to arbitrary code execution due to automatic, unsanitized import of a local tools.py file at startup. This allows an attacker with write access to the working directory to execute arbitrary Python code within the PraisonAI process and potentially compromise the host system and connected data. The vulnerability is fixed in version 4.5.139.
PraisonAI is a multi-agent teams system. Prior to 4.5.128, the Flask API endpoint in src/praisonai/api.py renders agent output as HTML without effective sanitization. The _sanitize_html function relies on the nh3 library, which is not listed as a required or optional dependency in pyproject.toml. When nh3 is absent (the default installation), the sanitizer is a no-op that returns HTML unchanged. An attacker who can influence agent input (via RAG data poisoning, web scraping results, or prompt injection) can inject arbitrary JavaScript that executes in the browser of anyone viewing the API output. This vulnerability is fixed in 4.5.128.