CVE-2026-56837

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, 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".