PraisonAI vulnerabilities

A vulnerability in PraisonAI before version 4.6.78 allows bypassing the shell command allowlist by using find's built-in actions (-exec, -execdir, -delete). Attackers can execute unauthorized commands, read or delete files without triggering shell metacharacter filters.

A path traversal vulnerability in PraisonAI (praisonaiagents) before version 1.6.78 in the FastContext feature. The FastContextAgent.execute_tool() function does not properly validate absolute paths or canonicalize relative paths, allowing reading, searching, and enumerating files outside the intended workspace directory.

PraisonAI before version 4.6.78 contains a path traversal vulnerability in the ContextGatherer component that fails to validate include paths in .praisoncontext and .praisoninclude files. Attackers can supply absolute paths or parent directory traversal sequences to read arbitrary files outside the workspace and include their contents in the generated context bundle.

PraisonAI before version 4.6.78 contains an unauthenticated server-side request forgery vulnerability in the Jobs API /api/v1/runs endpoint. The webhook_url parameter is validated at request time but re-resolved at connection time, allowing attackers to use DNS rebinding to reach internal services with a blind SSRF attack.

A vulnerability in PraisonAI (praisonaiagents) before version 1.6.78 automatically loads defaults from a project-local .praisonai/config.toml without validating the output.output_file path. An attacker can set this path to an absolute or '..' traversal path, causing agent.start() without an output parameter to overwrite files outside the project root.

In the multi-agent system PraisonAI prior to version 4.6.37, a vulnerability allows the exploitation of symlinks to write arbitrary data to a chosen location on the victim's filesystem. The issue stems from the lack of validation for member.linkname and not rejecting symlink/hardlink members.

In the multi-agent system PraisonAI, versions from 4.5.139 to before 4.6.32 have a vulnerability related to unauthorized file imports. The tool_override.py file lacks safeguards, allowing remote code execution by an attacker.

In PraisonAI prior to praisonaiagents 1.6.59, AgentTeam.launch and the Agents alias register GET /{path}/list, POST /{path}, and POST /{path}/{agent_id} without access-control checks before listing agents or calling agent.chat. A remotely exposed server can therefore let unauthenticated clients enumerate agents, consume model resources, access connected private context, and trigger agent tools or workflow side effects.

PraisonAI prior to version 4.6.78 has a vulnerability in the `deploy/api.py` module that generates Python server code by directly interpolating the `agents_file` parameter into an f-string, which is then written to a file and executed via `subprocess.Popen()`. An attacker who controls the `agents_file` value can inject arbitrary Python code.

In PraisonAI prior to 0.1.6, when PLATFORM_JWT_SECRET is unset, the public dev-secret-change-me HS256 signing key is used, and startup and token-issuance guards are disabled because PLATFORM_ENV defaults to dev. An unauthenticated attacker can sign a JWT with an arbitrary sub value that is accepted as an authenticated identity, enabling impersonation of a user or workspace owner.

In PraisonAI prior to 0.1.6, when PLATFORM_JWT_SECRET is unset, JWT_SECRET is assigned the public dev-secret-change-me value, and its production guard does not run when PLATFORM_ENV is also unset (defaults to dev). A remote unauthenticated attacker can mint an HS256 token with arbitrary sub and email, which is accepted by AuthService._verify_token() and get_current_user for protected API routes.

In PraisonAI prior to 1.7.2, the codeMode tool in src/praisonai-ts/src/tools/builtins/code-mode.ts executes model-generated JavaScript with new Function() and with(sandbox), while a regex blocklist can be bypassed with Function('return this')() to recover the global object and by dynamically constructing the child_process module name. An attacker who can influence the code argument can access host process capabilities, read or write files, obtain environment credentials, and execute OS commands with PraisonAI process privileges.

In PraisonAI from 1.6.0 until 1.7.2, AgentOS in src/praisonai-ts/src/os/agentos.ts uses the 0.0.0.0 default from src/praisonai-ts/src/os/config.ts and registers GET /api/agents and POST /api/chat without authentication middleware. A remote caller who can reach the service can obtain agent names, roles, and instruction prefixes and can invoke a selected agent, potentially reaching its tools, memory, external APIs, credentials, and workflow state.

In PraisonAI from 1.5.0 until 1.7.2, MCPServer.startHttp() in src/praisonai-ts/src/mcp/server.ts binds without a host restriction and forwards every HTTP POST request to handleRequest() without authentication or authorization. Any network client that can reach the port can call tools/list, tools/call, resources/read, or prompts/get, causing registered handlers to run with server-side credentials and process privileges or disclose registered data.

In PraisonAI from 1.4.0 until 1.7.2, codeMode in src/praisonai-ts/src/tools/builtins/code-mode.ts executes untrusted JavaScript with new Function() inside with(sandbox) and relies on a small source-code blocklist plus shadowed process and require properties. Code can use ({}).constructor.constructor to recover the real Function constructor, obtain process and process.mainModule.require, and reach host filesystem and subprocess APIs despite the advertised sandbox. Attackers who control codeMode input can read secrets, modify files, execute commands, or exhaust the host process.

In PraisonAI, a multi-agent teams system, prior to 4.6.62, src/praisonai/praisonai/tools/multiedit.py passes the LLM-controlled filepath parameter directly to open for reading and writing without traversal rejection, symlink resolution, a workspace boundary, or protected-path checks. Prompt-influenced agents can read or overwrite files.

In PraisonAI, a multi-agent teams system, prior to 4.6.58, praisonai.jobs.server.create_app mounts praisonai.jobs.router.create_router under /api/v1/runs without authentication or per-job authorization. Network clients can submit attacker-controlled prompts and agent configuration, list and read jobs, stream results, and cancel or delete other jobs.

In PraisonAI prior to 4.6.58, the APIKeyAuthMiddleware or JWTAuthMiddleware forwards requests when PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET and the corresponding recipe value are absent. As a result, unauthenticated clients can reach recipe execution, input, and output surfaces even though the operator explicitly enabled authentication.

In PraisonAI prior to 4.6.59, the default UI host applications expose POST /api/mcp/connect without mandatory authentication and accept caller-controlled command and args values that PraisonAIUI passes to StdioMCPClient to start a local process. Because the UI binds to 0.0.0.0 by default, a reachable unauthenticated client can execute commands as the UI service account even when the MCP handshake later fails.

In PraisonAI (prior to praisonai 4.6.59 and praisonaiagents 1.6.59), the unauthenticated POST /api/v1/runs Jobs API accepts an attacker-controlled agent_yaml field. The approve field can mark execute_command as YAML-approved before @require_approval checks critical tools, allowing a remote caller to make a configured LLM agent invoke arbitrary OS commands without credentials or operator interaction.

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, Browser Server _handle_connection() checks Chrome extension origins with re.match() and the unanchored expression chrome-extension://[a-z0-9]{32}. Extra trailing characters pass before websocket.accept(), allowing start_session commands and unauthorized browser automation. This issue is fixed in version 4.6.58.

PraisonAI before 4.6.40 contains a command injection vulnerability in the bundled Claude GitHub Actions workflow. The pull request branch name is embedded in a Bash block without validation, and any @claude comment can trigger the job, allowing outside contributors to execute arbitrary code in the runner.

PraisonAI prior to version 4.6.40 exposes an unauthenticated agent control API when CALL_SERVER_TOKEN is not set. The verify_token() helper fails open, and the call server binds to 0.0.0.0 by default, allowing any client to list, inspect, invoke, and unregister agents.

PraisonAI by default generates a Flask API server without authentication, listening on all network interfaces (0.0.0.0) and exposing sensitive endpoints. An attacker can send requests to /chat and /agents endpoints without any authentication, allowing execution of LLM code with API keys present in the environment.

In PraisonAI before version 4.6.40 (corresponding to praisonaiagents version 1.6.40), a vulnerability exists in the `execute_code()` function in `praisonaiagents/tools/python_tools.py`. An attacker can bypass the subprocess sandbox by using `print.__self__` to access the real Python `builtins` module, then extract `__import__` via `vars()` and runtime string construction, achieving arbitrary OS command execution on the host.

PraisonAI before version 4.6.40 includes an example A2A server that exposes an unauthenticated A2A JSON-RPC endpoint and registers a calculate(expression) tool implemented with Python eval(). The server binds to 0.0.0.0. A remote unauthenticated attacker can send message/send to /a2a, causing the LLM to invoke the calculate tool, leading to arbitrary Python execution on the server. The vulnerability affects deployments following the official A2A example or similar unauthenticated A2A deployments with unsafe tools.

PraisonAI before version 1.6.78 contains a remote code execution vulnerability in the CodeAgent._execute_python() function, which executes LLM-generated Python code without AST validation, import restrictions, or sandbox enforcement. Attackers can influence LLM output through prompt injection to exfiltrate all environment secrets and execute arbitrary code on the host system.

PraisonAI before version 4.6.78 contains arbitrary file write and command execution vulnerabilities in the AICoder component. Missing path validation and command sanitization in LLM tool calls allow attackers to inject malicious prompts through the chat interface.

A vulnerability in PraisonAI before version 4.6.78 allows SQL/CQL injection due to improper validation of the dimension argument in PGVector and Cassandra backends. An attacker can pass a malicious string that is directly interpolated into the CREATE TABLE query, potentially leading to unauthorized database operations.

PraisonAI before version 4.6.78 contains a code injection vulnerability in deploy/api.py where the agents_file parameter is directly interpolated into an f-string without sanitization. Attackers can inject arbitrary Python code that executes when the generated server code runs via subprocess.Popen().

PraisonAI is a multi-agent teams system. Prior to version 1.6.32, the URL checking logic in PraisonAI had a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

PraisonAI prior to 4.5.115 has a vulnerability in the AgentService.loadAgentFromFile method that uses the js-yaml library to parse YAML files without disabling dangerous tags (such as !!js/function and !!js/undefined). This allows an attacker to craft a malicious YAML file that, when parsed, executes arbitrary JavaScript code.

PraisonAI prior to version 1.5.115 has a vulnerability in the execute_code() function in sandbox mode. The AST blocklist in the subprocess is incomplete, allowing sandbox escape and arbitrary Python code execution.

PraisonAI prior to version 4.5.97 has a vulnerability in OAuthManager.validate_token() that returns True for any token not found in its internal store (empty by default). Any HTTP request to the MCP server with an arbitrary Bearer token is treated as authenticated, granting full access to all registered tools and agent capabilities.

PraisonAI is a multi-agent teams system. Prior to version 4.5.97, the PraisonAI Gateway server accepts WebSocket connections at /ws and serves agent topology at /info with no authentication. Any network client can connect, enumerate registered agents, and send arbitrary messages to agents and their tool sets.

PraisonAI prior to version 1.5.90 has a vulnerability in execute_code() that allows bypassing a three-layer sandbox by passing a str subclass with an overridden startswith() method, leading to arbitrary OS command execution.

PraisonAI versions 4.5.15 through 4.5.69 contain a vulnerability allowing arbitrary OS command execution via the --mcp CLI argument, which is passed without validation to shlex.split() and anyio.open_process(). An attacker can exploit this to execute arbitrary commands in the process user context.

PraisonAI is a multi-agent system. Prior to version 4.5.90, the get_all_user_threads function constructs raw SQL queries using f-strings with unescaped thread IDs from the database. An attacker stores a malicious thread ID via update_thread, and when the thread list is loaded, the injected SQL executes, granting full database access.

In PraisonAI before praisonaiagents 1.6.62, searxng_search and the search_web SearxNG provider pass the LLM-controlled searxng_url parameter directly to requests.get without validating scheme, host, port, or resolved address. Prompt-injected content can direct the search tool to internal JSON services, distinguish open and closed internal ports, and attempt cloud-metadata requests.

PraisonAI is a multi-agent teams system. From 1.4.0 until 1.7.2, createAgentLoop() in src/praisonai-ts/src/ai/agent-loop.ts passes executable tools to generateText() before invoking the onToolCall approval callback. Because the wrapped AI SDK executes tool handlers during generation, a callback that returns false records tool_rejected only after the denied tool has already produced side effects.

PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, CommandValidator in src/praisonai-ts/src/cli/features/sandbox-executor.ts validates only the first whitespace-delimited executable against allowedCommands, then SandboxExecutor passes the complete command string to sh -c. A command beginning with an allowed executable can append a non-allowlisted command through shell metacharacters.

PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, SandboxExecutor network-isolated mode in src/praisonai-ts/src/cli/features/sandbox-executor.ts uses buildEnv() only to inject invalid http_proxy and https_proxy environment variables and does not establish an OS-level network boundary. Programs that ignore those proxy variables can open sockets directly.

PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, MCPSecurity.evaluatePolicy() in src/praisonai-ts/src/mcp/security.ts invokes the configured credential validator only when AuthMethod is api-key or bearer. Basic and OAuth policies accept any non-empty Authorization header without calling auth.validate(), then return an authenticated result.

PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, the shell() helper exported from src/praisonai-ts/src/tools/utility-tools.ts checks only the first whitespace-delimited token against safeCommands and then passes the complete original string to child_process.exec(). A string that starts with an allowed read-only command can append a second non-allowlisted command through shell syntax.

In PraisonAI, ToolsMCPServer.run_sse() in src/praisonai-agents/praisonaiagents/mcp/mcp_server.py mounts SseServerTransport on the legacy /sse and /messages/ endpoints without default Host, Origin, or authentication enforcement. A malicious website can use DNS rebinding against a reachable local or internal SSE server, supply attacker-controlled Host and Origin headers, enumerate registered tools, and invoke them with the server user's privileges. An initial remediation was released in praisonaiagents 1.6.59 and PraisonAI 4.6.59.

In PraisonAI prior to 4.6.62, setting PRAISONAI_CALL_AUTH to disabled makes verify_token accept requests to /api/v1/agents/{id}/invoke without CALL_SERVER_TOKEN authentication. Deployments using the advertised opt-out can expose registered agents and their connected tools or private context to unauthenticated invocation.

In PraisonAI prior to 4.6.59, the WhatsApp and Linear bot webhook handlers verify HMAC signatures only when WHATSAPP_APP_SECRET or LINEAR_WEBHOOK_SECRET is configured, otherwise parsing and dispatching unsigned request bodies. A remote unauthenticated client reaching the webhook route can forge messages, comments, or agent-session events, impersonate platform users, and disrupt bot processing.

In PraisonAI prior to 4.6.59, the unauthenticated Jobs API accepts an absolute or traversing agent_file path in POST /api/v1/runs and passes it to the job executor without a workspace allowlist or boundary check. A remote caller can cause the server to open files accessible to the service account, exposing credentials, keys, environment variables, and other local data.

In PraisonAI 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 exposing code_read_file, code_search_replace, or code_apply_diff before set_workspace can let prompt-influenced calls read and modify files outside the intended project directory.

In PraisonAI prior to praisonaiagents 1.6.59, src/praisonai-agents/praisonaiagents/tools/email_tools.py interpolates LLM-controlled from_addr, subject, and query values directly into quoted IMAP SEARCH criteria. Embedded quote, backslash, newline, or null characters can escape the intended criterion and alter IMAP operations when search_emails, reply_email, or archive_email is exposed to an agent with configured email credentials, allowing mailbox data access, modification, deletion, or connection disruption.