PraisonAI vulnerabilities

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.

PraisonAI before version 4.6.51 exposes the /api/v1/runs endpoint without authentication. Any reachable caller can submit jobs, read results, cancel runs, or delete jobs using operator credentials. The fix adds PRAISONAI_JOBS_API_KEY middleware.

PraisonAI before version 4.6.58 has a flaw in create_auth_middleware() that allows requests when auth=api-key lacks PRAISONAI_API_KEY or JWT authentication lacks PRAISONAI_JWT_SECRET. An externally bound Recipe server can accept unauthenticated POST /v1/recipes/run requests despite authentication being enabled.

PraisonAI before version 4.6.58 has a flaw in MCP HTTP Stream _validate_origin that uses startswith, allowing attacker-controlled localhost.attacker.com origin to pass the allowlist. A webpage can send text/plain requests without preflight and invoke tools without an API key, including file writes.

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, _create_agents_app() and _create_unified_app() do not install a credential check, allowing unauthenticated callers to reach POST /agents and POST /api/v1/agents/{id}/invoke. This issue is fixed in version 4.6.58.

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, is_path_within_directory() uses os.path.abspath() rather than os.path.realpath() for the workspace boundary. A symlink inside workspace can point outside and still pass the check, allowing read_file and other code tools to access files outside the configured workspace. This issue is fixed in version 4.6.58.

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, _create_agents_app() does not authenticate POST /agents or POST /agents/{agent_name}. Missing or incorrect bearer and X-API-Key values still reach agent execution. This issue is fixed in version 4.6.58.

PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, JobSubmitRequest.validate_webhook_url() accepts webhook_url when resolution raises socket.gaierror because the exception path uses except socket.gaierror: pass. JobExecutor._send_webhook() later performs a fresh lookup, allowing DNS changes to direct the request to an internal service. This issue is fixed in version 4.6.58.

PraisonAI before version 4.6.58 has a vulnerability in the Jobs API where the validate_webhook_url() path fails open on socket.gaierror and does not bind the validated address to the later request. An attacker can supply a webhook_url that later resolves to 127.0.0.1, 169.254.169.254, or another internal address.

PraisonAI is a multi-agent teams system. From praisonai 4.6.34 until 4.6.58, _create_agents_app() does not authenticate POST /agents or POST /agents/{agent_name}. A network caller can invoke configured agents without credentials even when an API key was supplied. This issue is fixed in version 4.6.58.

PraisonAI before version 4.6.58 has a vulnerability in the MCP HTTP Stream handler where the mcp_post handler creates a new _sessions entry for every initialize request but does not call _cleanup_sessions or enforce a maximum. An unauthenticated attacker can exhaust memory.

PraisonAI before version 1.6.58 has a vulnerability in the ast_grep_rewrite function, which lacks the @require_approval decorator used by sibling mutation tools. With dry_run=False, an agent-controlled call can pass --update-all and a broad path to rewrite matching files without the expected authorization gate.

PraisonAI before version 4.6.58 has a vulnerability in the _validate_origin method of MCP HTTP Stream, which accepts request_origin.startswith(allowed), allowing an attacker to use the localhost.evil.example origin that matches the localhost allowlist. Without an API key, a malicious webpage can submit tools/call requests to the local MCP server and execute exposed tools.

PraisonAI is a multi-agent system. Prior to praisonaiagents 1.6.58, AgentServer exposes ServerConfig.auth_token but AgentServer._create_app does not check it on any route. A remote caller can subscribe, publish, and perform other actions without a valid bearer token or X-Auth-Token even when authentication is configured. This issue is fixed in version 1.6.58.

PraisonAI is a multi-agent system. Prior to praisonaiagents 1.6.58, the FileMemory constructor joins unsanitized user_id into self.user_path. A caller supplying ../ or path separators can escape the memory directory and write JSON data to arbitrary process-writable locations. The fix sanitizes user_id before constructing self.user_path. This issue is fixed in version 1.6.58.

PraisonAI is a multi-agent system. Prior to praisonaiagents 1.6.58, spider_tools._host_is_blocked() does not resolve ordinary hostnames before scrape_page fetches them. A hostname such as 127.0.0.1.nip.io passes validation and resolves to loopback, permitting internal HTTP access. The fix uses socket.getaddrinfo and fails closed on DNS errors. This issue is fixed in version 1.6.58.

PraisonAI is a multi-agent system. Prior to praisonaiagents 1.6.58, the web_crawl function validates only the initial URL before _crawl_with_httpx uses httpx.Client(follow_redirects=True). Redirect targets are not revalidated, so an attacker who influences a crawl target can redirect a public URL to loopback, private network, or cloud metadata services while ALLOW_LOCAL_CRAWL remains disabled. The fetched internal response is returned to the agent context. This issue is fixed in version 1.6.58.

PraisonAI Platform API prior to version 0.1.4 has two authorization failures that together break workspace isolation. The service layer performs global primary-key lookups without checking workspace ownership, and member management endpoints only require min_role='member', allowing any member to promote themselves to owner and remove the original owner.

PraisonAI before version 1.6.58 contains an SSRF vulnerability in the web_crawl tool. The protection only checks the initial URL, but after redirects or DNS rebinding it connects to internal addresses such as loopback, private networks, or cloud metadata. An attacker can influence the URL passed to web_crawl to obtain responses from these internal resources.

PraisonAI versions 1.5.128 through 1.6.57 contain an SSRF vulnerability in the web_crawl() function. Despite initial URL validation, redirect targets are not checked, allowing an attacker to access internal resources via a public URL that redirects to loopback or private networks. This is an incomplete fix for previous SSRF vulnerabilities.

PraisonAI versions 3.9.26 through 4.6.57 (praisonai) and 0.12.12 through 1.6.57 (praisonaiagents) have a code execution vulnerability in the workflow include feature. The _execute_include() function imports and runs code from tools.py without proper safeguards, allowing an attacker to execute arbitrary Python code if they can influence a local workflow directory.

A vulnerability in PraisonAI versions prior to 4.6.40 allows arbitrary code execution through unguarded spec.loader.exec_module calls in agents_generator.py. These functions accept a module_path parameter from YAML configuration and execute it without validation, allowing an attacker to execute remote code.

Vulnerability in PraisonAI (versions prior to 4.6.40) where hidden metadata in a webpage causes PraisonAI agents to write attacker-controlled content to arbitrary paths. The write_file function skips path validation when workspace=None (always in production).

Vulnerability in PraisonAI (versions before 4.6.40) allows automatic fetching of content from URLs mentioned in CLI prompts. An attacker can inject a malicious URL, resulting in fetching localhost resources and injecting them into the model context, with no private address restrictions.

Vulnerability in PraisonAI (versions before 4.6.40) – incomplete fix for previous flaw (CVE-2026-44336). An unauthenticated attacker can read any file on the host (e.g., /etc/passwd, SSH keys) via MCP tools/call to praisonai.workflow.show.

In PraisonAI before version 4.6.40 (and praisonaiagents before 1.6.40), URL validation in `spider_tools` can be bypassed using alternate loopback host encodings. The validation only blocks exact strings like 'localhost' and '127.0.0.1', allowing SSRF to loopback services.

PraisonAI before version 1.6.78 contains a remote code execution vulnerability in the plugin manager. It loads and executes arbitrary Python (.py) files from .praisonai/plugins/ directories without code signing, integrity verification, or sandboxing. An attacker who can write a malicious .py file to a plugin directory (e.g., via path traversal, supply chain attack, or compromised dependency) achieves arbitrary code execution when the plugin system initializes.

PraisonAI before version 1.6.78 contains a remote code execution vulnerability in SkillTools.run_skill_script() that executes scripts without path containment validation. Attackers can supply absolute file paths to execute arbitrary scripts from any filesystem location, including those outside the intended working directory.

PraisonAI before version 4.6.78 contains a remote code execution vulnerability in the JobWorkflowExecutor._exec_inline_python() function due to insufficient AST validation of workflow script steps. Attackers can create malicious YAML workflow files with import os statements followed by os.system() calls that bypass sandbox checks and execute arbitrary OS commands with process privileges.

A vulnerability in PraisonAI before version 4.6.78 in AgentMail webhook mode fails to verify Svix webhook signatures, allowing unauthenticated attackers to forge message.received events. Attackers can send crafted JSON payloads to the webhook endpoint to invoke configured agents with arbitrary sender addresses and message content.

A vulnerability in PraisonAI before version 4.6.78 allows authentication bypass in the Call API agent invocation endpoints (agent_invoke.py) when PRAISONAI_CALL_AUTH=disabled is configured. The safeguard restricting access to localhost relies on the HTTP Host header, which can be spoofed by an attacker.

PraisonAI before version 4.6.78 unsafely encodes deployment configuration values when generating Python source code for API servers. Attackers can inject arbitrary Python expressions through the deploy.api.host and agents_file configuration parameters, which execute when the server starts or handles requests.

PraisonAI before version 1.6.78 contains a server-side request forgery (SSRF) vulnerability in the web_crawl tool. It validates hostnames at check time but re-resolves them at connection time without IP pinning. Attackers can use DNS rebinding to bypass SSRF protection and retrieve internal HTTP response bodies from private or loopback services.

PraisonAI before version 4.6.78 exposes the MCP HTTP-stream transport without authentication by default. When an operator runs the server without an API key, an unauthenticated client can initialize a session, enumerate available tools, and invoke them. Additionally, the server does not validate tool-call arguments against the advertised inputSchema.

The vulnerability in PraisonAI before version 1.6.78 caches tool approval decisions solely by tool name, allowing attackers to reuse initial approvals for subsequent calls with arbitrary arguments. Attackers can exploit this by obtaining approval for a benign operation and then executing dangerous file write operations with unreviewed parameters in the same session.

PraisonAI before version 4.6.78 has a vulnerability where the default Subprocess Sandbox backend ignores all configured security policies. Blocked commands, paths, imports, subprocess restrictions, and file write restrictions are completely bypassed.

A vulnerability in PraisonAI before version 4.6.78 stems from a misconfigured prompt injection defense where the default block threshold is set to CRITICAL severity. This allows HIGH-severity attacks to pass through unblocked, enabling system prompt extraction and unauthorized tool invocations.

An SSRF vulnerability in the Crawl4AI/Chromium backend of PraisonAI before version 1.6.78 allows attackers to bypass SSRF validation via DNS rebinding and HTTP redirects. Attackers can craft URLs that resolve to internal services after initial validation, enabling the headless browser to read sensitive internal responses including canary values.

PraisonAI before version 1.7.3 has an insecure default configuration that binds to all network interfaces, requires no API key, and allows wildcard CORS. Unauthenticated attackers can read agent instructions and system prompts via GET /api/agents or invoke agents without authentication via POST /api/chat.