p PatchFirst

PatchFirst · Latest vulnerabilities

praisonai vulnerabilities

Vulnerabilities published for praisonai in the last 30 days: 15. Listed in the KEV catalogue: 0.

RSS ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 104

  1. CVE-2026-57117

    High · CVSS 8.8Fix available

    PraisonAI: Compute-bridged file tools allow shell command injection

    PraisonAI is a multi-agent teams system. From version 4.6.10 to before version 4.6.59, LocalManagedAgent / SandboxedAgent compute bridging wraps read_file, list_files, and write_file when a compute provider is attached. The bridge converts those file operations into shell command strings using raw path arguments, then sends those strings to shell-backed compute providers. 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. With compute="local", commands execute through the local subprocess compute provider on the host. With Docker, commands e

    • Update to 4.6.59
    Published Updated
  2. CVE-2026-57146

    High · CVSS 7.5Fix available

    PraisonAI A2U incomplete authentication fix leaves current serve command unauthenticated by default

    PraisonAI is a multi-agent teams system. From version 4.5.115 to before version 4.6.61, the published A2U advisory GHSA-f292-66h9-fpmf says unauthenticated A2U event streaming was fixed in praisonai 4.5.115. Current head still exposes the same A2U subscription and event routes without authentication when the operator starts the documented CLI entrypoint. The current CLI wrapper does not expose --api-key, does not install the common API-key middleware, and does not generate a token for A2U. It calls create_a2u_routes(app) directly. That helper only enforces auth if A2U_AUTH_TOKEN is already present; if the variable is missing, _authenticate_re

    • Update to 4.6.61
    Published Updated
  3. CVE-2026-57144

    High · CVSS 8.8Fix available

    PraisonAI SandlockSandbox falls back to unrestricted subprocess execution when Landlock is unavailable

    PraisonAI is a multi-agent teams system. From version 4.5.110 to before version 4.6.61, praisonai.sandbox.SandlockSandbox is documented and implemented as the kernel-enforced sandbox backend for untrusted code. Its SandboxConfig.native() path lets callers configure allowed filesystem paths and network=False. On systems where the optional sandlock module imports but reports that Landlock is unavailable, SandlockSandbox.execute() and run_command() do not fail closed. They silently fall back to SubprocessSandbox(self.config). That fallback keeps the same high-level native policy object but does not enforce the native filesystem or network bounda

    • Update to 4.6.61
    Published Updated
  4. CVE-2026-57142

    High · CVSS 7.8Fix available

    PraisonAI recipe workflow policy can be bypassed by declaring and YAML-approving dangerous tools outside TEMPLATE.yaml

    PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.61, PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools. For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context. As a result, an untrusted recipe can omit execute_command

    • Update to 4.6.61
    Published Updated
  5. CVE-2026-57116

    Critical · CVSS 9.8Fix available

    PraisonAI: AgentOS remains unauthenticated after GHSA-pm96 patched version and allows remote agent invocation

    PraisonAI is a multi-agent teams system. From version 4.2.1 to before version 4.6.59, PraisonAI's AgentOS FastAPI deployment surface remains unauthenticated in current main and in releases after the published patched version for GHSA-pm96-6xpr-978x / CVE-2026-40151. The chat route directly calls agent.chat(request.message). No-auth and wrong-bearer requests both execute the deployed agent. This is broader than passive metadata disclosure. In any deployment where AgentOS wraps agents with tools, private context, memory, API integrations, or cost-bearing model calls, an unauthenticated reachable client can drive those agents. This issue has bee

    • Update to 4.6.59
    Published Updated
  6. CVE-2026-57114

    High · CVSS 7.2Fix available

    PraisonAI: Jobs webhook SSRF protection bypass via DNS rebinding

    PraisonAI is a multi-agent teams system. From version 4.5.126 to before version 4.6.59, PraisonAI's Async Jobs API validates webhook_url when a job request is parsed and again when the internal Job object is constructed. That validation blocks direct loopback/private targets, but it is not bound to the later network request. When a job completes, _send_webhook() passes the original hostname to httpx.AsyncClient.post() with no send-time validation, IP pinning, or guarded transport. An attacker-controlled hostname can therefore resolve to a public IP during Pydantic validation and later resolve to loopback/private/cloud-metadata infrastructure

    • Update to 4.6.59
    Published Updated
  7. CVE-2026-57113

    High · CVSS 8.1Fix available

    PraisonAI GitHub template cache path traversal allows outside-cache file write and directory deletion

    PraisonAI is a multi-agent teams system. From version 2.6.0 to before version 4.6.59, PraisonAI's template loader accepts GitHub template URIs with refs, for example github:owner/repo/[email protected]. The resolver stores the user-controlled template path and ref verbatim, and the cache layer later joins those values into ~/.praison/cache/templates/github/<owner>/<repo>/<template>/<ref> without normalizing each segment or checking that the final path remains inside the template cache root. A crafted ref such as ../../../../../../outside-delete-target therefore escapes the cache directory. The first load can write .cache_meta.json outside the c

    • Update to 4.6.59
    Published Updated
  8. CVE-2026-56840

    High · CVSS 8.8Fix available

    PraisonAI: HTTPApproval dashboard renders tool arguments as raw HTML, allowing approval-page XSS to approve dangerous tools

    PraisonAI is a multi-agent teams system. From version 4.5.2 to before version 4.6.59, 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 to inspect the risky tool request, 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. This issue has been patched in version 4.6.59.

    • Update to 4.6.59
    Published Updated
  9. CVE-2026-56838

    High · CVSS 7.8Fix available

    PraisonAI recipe.run_stream skips dangerous-tool policy enforcement

    PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.59, PraisonAI recipe execution blocks default-denied dangerous tools unless the caller explicitly passes allow_dangerous_tools=True. The normal recipe.run() path enforces this with _check_tool_policy(). The streaming path, recipe.run_stream(), loads the same recipe, checks dependencies, and then calls _execute_recipe() without running the dangerous-tool policy check. As a result, a recipe that honestly declares execute_command in TEMPLATE.yaml requires.tools is denied by recipe.run(), but reaches the execution engine through recipe.run_stream() with allow_dange

    • Update to 4.6.59
    Published Updated
  10. CVE-2026-56837

    High · CVSS 8.6Fix available

    PraisonAI LinearBot processes unsigned webhooks when LINEAR_WEBHOOK_SECRET is missing

    PraisonAI is a multi-agent teams system. From version 4.6.56 to before version 4.6.59, PraisonAI's LinearBot starts a public webhook listener on 0.0.0.0 and treats LINEAR_WEBHOOK_SECRET as optional. When the secret is absent, startup only logs a warning and _handle_webhook() skips Linear-Signature verification entirely. An unauthenticated network caller who can reach the webhook endpoint can submit a forged Linear-Event: AgentSession request. The forged request is parsed, scheduled for background processing, dispatched to _handle_agent_session(), and passed into BotSessionManager.chat(). The bot then attempts to post the agent response back t

    • Update to 4.6.59
    Published Updated
  11. CVE-2026-56836

    High · CVSS 8.2Fix available

    PraisonAI recipe serve Typer command bypasses the non-localhost authentication guard

    PraisonAI is a multi-agent teams system. From version 4.5.112 to before version 4.6.59, PraisonAI's installed console entrypoint is Typer-first. In current releases, the recipe command is registered in the Typer app and praisonai recipe serve dispatches to the deprecated Typer command in src/praisonai/praisonai/cli/commands/recipe.py. That Typer command can start the Recipe HTTP server on a non-localhost interface with no authentication. It prints a deprecation warning, and then launches the server. Because config.auth is absent, create_app() does not attach the API-key or JWT middleware. Unauthenticated requests can then reach the recipe API

    • Update to 4.6.59
    Published Updated
  12. CVE-2026-56835

    High · CVSS 8.3Fix available

    PraisonAI Slack app_mention bypasses configured user/channel authorization

    PraisonAI is a multi-agent teams system. From version 3.11.0 to before version 4.6.59, PraisonAI's 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 Slack app_mention event handler. A Slack workspace user who can mention the bot in a channel where the Slack app is present can trigger the configured PraisonAI agent even when: the sender is not in BotConfig.allowed_users; the channel is not in BotConfig.allowed_channels; unknown_user_policy="deny" is configured; and the same event content is correctly dropped by the normal message

    • Update to 4.6.59
    Published Updated
  13. CVE-2026-56834

    High · CVSS 7.5Fix available

    PraisonAI dynamic-context artifact tools read arbitrary host files outside artifact storage

    PraisonAI is a multi-agent teams system. From version 3.8.1 to before version 4.6.59, PraisonAI's Dynamic Context Discovery feature exposes artifact helper tools through ctx.get_tools(). The implemented artifact tools do not enforce that the supplied artifact_path is an artifact created by the configured store or that it lives under the configured artifact base directory. Instead, artifact_head, artifact_tail, artifact_grep, and artifact_chunk wrap the caller-supplied path directly into an ArtifactRef and then read it from the host filesystem. As a result, any prompt/user/tool-caller that can influence those tool arguments can read files read

    • Update to 4.6.59
    Published Updated
  14. CVE-2026-56833

    High · CVSS 7.5Fix available

    PraisonAI Dynamic Context history and terminal tools read files outside configured storage via path traversal

    PraisonAI is a multi-agent teams system. From version 3.8.1 to before version 4.6.59, PraisonAI's Dynamic Context module provides filesystem-backed history and terminal-log storage. The module also exports agent-callable tool factories. Those tools accept run_id and agent_id arguments from the tool caller. The underlying stores join those values into filesystem paths without rejecting absolute paths or .. traversal. Because run_id can be an absolute path and agent_id can contain traversal, a lower-trust prompt/user that can call these tools can read .jsonl and .log files outside the configured Dynamic Context base directory. This issue has be

    • Update to 4.6.59
    Published Updated
  15. CVE-2026-56832

    High · CVSS 8.8Fix available

    PraisonAI DiscordApproval accepts unrelated channel messages as dangerous-tool approvals

    PraisonAI is a multi-agent teams system. From version 4.5.2 to before version 4.6.59, 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 configured approval channel can approve a pending high-risk tool call by sending yes after the approval message appears. the same PoV also shows that the Slack and Telegram messaging approval backends have no explicit approver allowlist parameter, but the primary report-grade issue is the Discord backend's unthreaded channel c

    • Update to 4.6.59
    Published Updated
  16. CVE-2026-57112

    High · CVSS 8.3EPSS 0.22%Fix available

    PraisonAI ToolsMCPServer legacy SSE transport accepts attacker Host/Origin and exposes registered tools

    PraisonAI is a multi-agent teams system. From praisonaiagents 0.6.0 until 1.6.59 and PraisonAI 3.10.0 until 4.6.59, 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. The Streamable HTTP transport rejects the same hostile Origin, which isolates the flaw to the leg

    • Update to 4.6.59
    Published Updated
  17. CVE-2026-57145

    Critical · CVSS 9.1EPSS 0.54%Fix available

    PraisonAI: Arbitrary File Read/Write via `multiedit` Tool Without Path Validation

    PraisonAI is 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 files through edit and diff behavior or overwrite files accessible to the process, exposing secrets and enabling persistence or application tampering. This issue is fixed in 4.6.62.

    • Update to 4.6.61
    Published Updated
  18. CVE-2026-57132

    High · CVSS 8.2EPSS 0.51%Fix available

    PraisonAI: PRAISONAI_CALL_AUTH=disabled environment variable unconditionally disables authentication

    PraisonAI is a multi-agent teams system. 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 that use the application's advertised opt-out can expose registered agents and their connected tools or private context to unauthenticated invocation. The vulnerability is fixed in 4.6.62.

    • Update to 4.6.61
    Published Updated
  19. CVE-2026-57131

    Critical · CVSS 9.8EPSS 0.97%Fix available

    praisonai: Jobs API exposes agent-execution endpoints with no authentication

    PraisonAI is 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, exposing service credentials and connected tool capabilities to unauthorized agent execution. This vulnerability is fixed in 4.6.58.

    • Update to 4.6.59
    Published Updated
  20. CVE-2026-57124

    Critical · CVSS 9.8EPSS 1.03%Fix available

    PraisonAI UI MCP connect endpoint allows unauthenticated local command execution

    PraisonAI is a multi-agent teams system. 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 commands bind 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. This vulnerability is fixed in 4.6.59.

    • Update to 4.6.59
    Published Updated

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →