PraisonAI vulnerabilities

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.

A vulnerability in PraisonAI before version 4.6.78 fails to validate file path references in custom command templates, allowing attackers to read files outside the workspace. Attackers can use path traversal sequences like @../outside_secret.txt or absolute paths to exfiltrate process-readable files into model prompts.

In PraisonAI (pip package praisonaiagents) before version 1.6.78, an unsafe dynamic module loading vulnerability exists in AgentFlow._resolve_pydantic_class. When a workflow step uses an output_pydantic reference, the framework imports a sibling tools.py from the workflow file's directory without sandboxing, ignoring PRAISONAI_ALLOW_*_TOOLS environment variables. An attacker controlling a workflow file and its sibling tools.py can execute arbitrary Python code with the workflow runner's privileges.

A vulnerability in PraisonAI before version 4.6.78 allows bypassing the prompt injection defense mechanism. The defense only blocks threats classified as CRITICAL, requiring three or more detector families to match simultaneously. Attackers can craft single or double-vector prompt injections classified as HIGH threat level, which pass through unblocked to the model.

PraisonAI before version 0.1.7 fails to validate that the project_id in issue create and update request bodies belongs to the URL workspace. An attacker can create issues referencing projects from other workspaces, causing cross-tenant data pollution in project statistics aggregation without workspace constraints.

PraisonAI before 1.5.128 contains a cross-origin agent execution vulnerability in the AGUI endpoint that allows remote attackers to trigger arbitrary agent execution. The POST /agui endpoint lacks authentication and hardcodes Access-Control-Allow-Origin: * headers, enabling attackers to bypass CORS preflight checks.

PraisonAI before 4.5.128 contains an arbitrary shell command execution vulnerability where the UI modules hardcode approval_mode to auto, overriding administrator configuration from PRAISON_APPROVAL_MODE environment variable. Authenticated attackers can instruct the LLM agent to execute arbitrary shell commands.

PraisonAI versions before 1.5.128 cache tool approval decisions based only on tool name, not invocation arguments, allowing subsequent execute_command calls to bypass approval prompts.

PraisonAI before version 4.5.115 contains a template injection vulnerability in the create_agent_centric_tools() function. User input passed to agent.start() is processed without proper escaping, allowing template expressions to be executed instead of being treated as literal text.

PraisonAI before version 4.5.115 exposes the A2U (Agent-to-User) event stream server without authentication. The create_a2u_routes() function registers endpoints /a2u/info, /a2u/subscribe, /a2u/events/{stream_name}, /a2u/events/sub/{id}, and /a2u/health with no access controls.

PraisonAI before version 4.5.97 contains a vulnerability in SubprocessSandbox in all modes (BASIC, STRICT, NETWORK_ISOLATED). The subprocess.run() function is called with shell=True and relies solely on string-pattern matching to block dangerous commands. The blocklist does not include sh or bash as standalone executables, allowing trivial sandbox escape in STRICT mode via sh -c '<command>'.

In PraisonAI before version 1.5.95, the FileTools.download_file() function does not validate the URL parameter, passing it directly to httpx.stream() with follow_redirects=True. An attacker controlling the URL can reach any host accessible from the server, including cloud metadata and internal services.

Vulnerability in PraisonAI before version 4.5.90, where MCPToolIndex.search_tools() compiles a caller-supplied string directly as a Python regular expression without validation, sanitization, or timeout. A crafted regex causes catastrophic backtracking in the re engine, blocking the Python thread for hundreds of seconds and causing a complete service outage.