PraisonAI vulnerabilities

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 PraisonAI from version 4.2.1 to before 4.6.59, the AgentOS FastAPI deployment surface remains unauthenticated despite the earlier fix for CVE-2026-40151. The chat route directly calls agent.chat(request.message), and both no-auth and wrong-bearer requests execute the deployed agent.

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.133 has an SQL identifier injection vulnerability in SQLiteConversationStore where the table_prefix value is directly concatenated into SQL queries without validation. An attacker controlling table_prefix can inject arbitrary SQL fragments, altering query structure.

The browser bridge in PraisonAI (versions below 4.5.139 and praisonaiagents below 1.5.140) is vulnerable to unauthenticated remote session hijacking due to missing authentication and a bypassable origin check on the /ws WebSocket endpoint. The server binds to 0.0.0.0 by default and accepts clients that omit the Origin header.

The workflow engine in PraisonAI (versions below 4.5.139 and praisonaiagents below 1.5.140) allows arbitrary command and code execution through untrusted YAML files. Steps supporting run:, script:, and python: are executed without validation, sandboxing, or user confirmation.

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 from version 4.5.115 to before 4.6.61, the documented CLI entrypoint still exposes A2U subscription and event routes without authentication. The CLI wrapper does not expose --api-key, does not install API-key middleware, and does not generate a token for A2U; if A2U_AUTH_TOKEN is missing, authentication is treated as disabled. The issue is patched in version 4.6.61.

In PraisonAI from version 4.5.110 to before 4.6.61, SandlockSandbox, intended as a kernel-enforced sandbox, does not fail closed when the optional sandlock module imports but reports Landlock unavailable. Its execute() and run_command() methods silently fall back to SubprocessSandbox, which does not enforce filesystem or network boundaries. The issue is patched in version 4.6.61.

In PraisonAI from version 4.5.87 to before 4.6.61, the dangerous-tool policy only checks tools declared in TEMPLATE.yaml requires.tools. For steps-based recipes, workflow.yaml is loaded by YAMLWorkflowParser, which resolves agent-level tools and preserves top-level approve:, allowing an untrusted recipe to declare execute_command and self-approve it without allow_dangerous_tools=True. The issue is patched in version 4.6.61.

In PraisonAI versions 4.6.10 to before 4.6.59, the LocalManagedAgent / SandboxedAgent bridging converts file operations (read_file, list_files, write_file) into shell command strings using raw path arguments. An attacker who can influence a file-tool path argument can break out of the quoted path and execute arbitrary shell commands in the compute environment (host or Docker container).

In PraisonAI versions 4.5.126 to before 4.6.59, the Async Jobs API validates webhook_url at parse time and job construction but not at send time. An attacker-controlled hostname can resolve to a public IP during validation and later to loopback/private/cloud-metadata infrastructure during webhook delivery, bypassing the SSRF guard. This is an incomplete fix / patch bypass for GHSA-8frj-8q3m-xhgm.

In PraisonAI versions 2.6.0 to before 4.6.59, the template loader accepts GitHub template URIs with refs and stores the user-controlled path and ref verbatim, joining them into the cache path without normalization or containment checks. A crafted ref with ../ sequences escapes the cache directory, can write .cache_meta.json outside the cache, and under certain conditions reaches shutil.rmtree to delete an attacker-selected outside directory.

In PraisonAI, praisonai.bots.HTTPApproval renders pending tool approval arguments directly into the approval dashboard HTML. An attacker-controlled tool argument can inject JavaScript into that page. When a human opens the approval URL, the script runs in the dashboard origin and can POST to the same request's /approve/{request_id}/decide endpoint, causing HTTPApproval to return approved=True.

In PraisonAI, the normal recipe.run() path enforces the dangerous-tool policy via _check_tool_policy(), but the streaming path recipe.run_stream() loads the same recipe and calls _execute_recipe() without running that check. As a result, a recipe declaring execute_command in requires.tools is denied by recipe.run() but reaches the execution engine through recipe.run_stream() with allow_dangerous_tools=False.

In PraisonAI, LinearBot starts a public webhook listener on 0.0.0.0 and treats LINEAR_WEBHOOK_SECRET as optional. When the secret is absent, _handle_webhook() skips Linear-Signature verification entirely. An unauthenticated network caller can submit a forged Linear-Event: AgentSession request, which is parsed, scheduled, and passed into BotSessionManager.chat().

In PraisonAI, the praisonai recipe serve command dispatches to a deprecated Typer command that can start the Recipe HTTP server on a non-localhost interface with no authentication. Because config.auth is absent, create_app() does not attach API-key or JWT middleware. Unauthenticated requests can reach the recipe API and, when enabled, /admin/reload.

In PraisonAI, the Slack bot applies its configured allowed_users, allowed_channels, and unknown-user pairing policy in the normal Slack message event handler, but not in the adjacent app_mention event handler. A Slack workspace user who can mention the bot can trigger the agent even when the sender is not in allowed_users, the channel is not in allowed_channels, and unknown_user_policy="deny".

In PraisonAI, the Dynamic Context Discovery feature exposes artifact helper tools through ctx.get_tools() that do not enforce that the supplied artifact_path is an artifact created by the configured store or lives under the configured artifact base directory. The artifact_head, artifact_tail, artifact_grep, and artifact_chunk tools wrap the caller-supplied path into an ArtifactRef and read it from the host filesystem, allowing reads of files readable by the PraisonAI process such as .env files, cloud credentials, and SSH keys.

In PraisonAI, the Dynamic Context module provides filesystem-backed history and terminal-log storage and exports agent-callable tool factories. These tools accept run_id and agent_id arguments, and the underlying stores join those values into filesystem paths without rejecting absolute paths or .. traversal. Since run_id can be an absolute path and agent_id can contain traversal, a lower-trust caller can read .jsonl and .log files outside the configured Dynamic Context base directory.

In PraisonAI, praisonai.bots.DiscordApproval approves a pending dangerous tool call when it sees any later non-bot message in the configured Discord channel whose text is classified as approval, such as yes. As a result, any user who can post in the approval channel can approve a pending high-risk tool call by sending yes after the approval message appears.