Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
105 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
PraisonAI's praisonai serve agents command exposes --api-key as the documented authentication control for production/external deployments, but the configured key is not enforced on the public agent invocation compatibility endpoints. An operator can start the server with --api-key and bind it to 0.0.0.0, but any network- reachable caller can still invoke agents through POST /agents or POST /agents/ {agentname} without Authorization, X-API-Key, a query token, or any other credential. Confirmed vulnerable: - v4.6.48 / commit d5f1114aaf1a2e9f121a6e66b929149ca2201f1d - v4.6.34 / commit e5928449f73f66cc8af1de61621aa974ab255133 Likely affected range: = 4.6.34, <= 4.6.48. This is distinct from CVE-2026-44338 / GHSA-6rmh-7xcm-cpxj, which covered the legacy Flask apiserver.py path before 4.6.34. This report concerns the newer FastAPI serve agents --api-key code path and is confirmed in v4.6.48. Details The CLI accepts and forwards an API key: -…
Recommended action: Upgrade to 4.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PraisonAI MCP HTTP-stream server creates a new in-memory session on every initialize request and never removes it. The cleanup routine that would expire sessions (cleanupsessions) is defined but never called anywhere in the codebase, and the configured session TTL is never enforced. There is no cap on the number of sessions. Because initialize requires no authentication and the server keeps every session dictionary forever, an attacker who can reach the endpoint (directly when the server is bound to a routable address, or from a victim's browser via the separate Origin-validation bypass) can drive memory usage up without bound until the process is killed by the out-of-memory killer. The same unbounded-growth pattern also applies to the cancelled-requests set populated by notifications/cancelled. Details In transports/httpstream.py, each initialize creates and stores a session with no limit: A cleanup method exists: but grep across the package shows it has no call sites:…
Recommended action: Upgrade to 4.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI's MCP HTTP Stream transport uses an unsafe prefix match when validating the Origin header. The default localhost allowlist includes origins such as http://localhost, and the validation accepts any origin that starts with an allowed value. As a result, an attacker-controlled origin such as http://localhost.evil.example passes the localhost origin check. When the MCP HTTP Stream server is started without an API key, which is the CLI default, this allows a malicious webpage to trigger unauthenticated MCP tools/call requests against a locally running PraisonAI MCP server. This is best framed as a browser-mediated localhost attack / DNS-rebinding-style Origin validation bypass. The default server binds to 127.0.0.1, so this is not a directly internet-facing unauthenticated API in the default configuration. Details Relevant source locations: - src/praisonai/praisonai/mcpserver/cli.py - src/praisonai/praisonai/mcpserver/transports/httpstream.py -…
Recommended action: Upgrade to 4.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset. This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution. The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs. This is distinct from the previously published toolresolver.py, api/call.py, templates/tooloverride.py, and agentsgenerator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature. Affected Components -…
Recommended action: Upgrade to 4.6.58 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 runcommand() 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 boundary during code execution. A sandboxed payload can read files outside the configured allowed path and open network connections despite network=False. Technical Details SandboxConfig.native() creates a restricted native policy and records caller-provided writable paths plus the requested network posture: SandlockSandbox builds the intended kernel policy with Landlock-backed filesystem allowlisting and network denial: However,…
Recommended action: Upgrade to 4.6.61 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Setting PRAISONAICALLAUTH=disabled completely disables all authentication on the /api/v1/agents/{id}/invoke endpoint. This bypass is advertised in the application's own error messages, making it likely to appear in production Docker and Compose configurations. Details The application's own error message advertises the bypass: "Set CALLSERVERTOKEN or PRAISONAICALLAUTH=disabled to run without authentication." This causes the setting to appear in Docker/Compose configurations as a convenience option. Proof of Concept Common vulnerable deployment: Impact Full unauthenticated access to the agent invocation API. Any agent registered on the server can be triggered without credentials, potentially executing arbitrary actions depending on the agent's configured tools.
Recommended action: Upgrade to 4.6.61 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The multiedit tool in src/praisonai/praisonai/tools/multiedit.py allows LLM-controlled arbitrary file read and write without any path validation, workspace boundary check, or protected path guard. This enables an attacker who can influence agent tool arguments (via crafted prompts, user input in chat bots, or malicious YAML workflow configs) to read sensitive files (e.g., /etc/shadow, ~/.ssh/idrsa, ~/.aws/credentials) and overwrite arbitrary files on the filesystem. Details The filepath parameter is used directly with open() for both reading (line 74) and writing (line 130) without any of the following protections that exist in other tools in the same codebase: 1. No .. path traversal check — unlike filetools.py (line 66: if '..' in filepath: raise ValueError) and edittools.py (line 35). 2. No workspace boundary validation — unlike filetools.py (validatepath with os.path.commonpath check) and skilltools.py (readskillfile with workspace boundary check). 3. No protected path…
Recommended action: Upgrade to 4.6.61 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 createa2uroutes(app) directly. That helper only enforces auth if A2UAUTHTOKEN is already present; if the variable is missing, authenticaterequest() returns None and treats auth as disabled. This is an incomplete-fix report for the published A2U issue, not a separate trust-model-only concern. Technical Details The Typer command for A2U accepts only --host and --port: It forwards only those values to the shared serve handler: The serve handler for A2U likewise accepts only host and port, then creates the app: createa2uapp() registers A2U routes directly: No call to…
Recommended action: Upgrade to 4.6.61 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allowdangeroustools=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 executecommand from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents..tools, and add top-level approve: [executecommand]. The caller did not set allowdangeroustools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool. The local PoV uses a harmless printf canary and explicitly unsets PRAISONAIAUTOAPPROVE. Technical Details recipe.run() checks the recipe policy…
Recommended action: Upgrade to 4.6.61 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI's template loader accepts GitHub template URIs with refs, for example github:owner/repo/template@v1.0.0. 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 .cachemeta.json outside the cache. If the normal cache hierarchy for the same owner/repo/template has already been created, the same path reaches shutil.rmtree(cachepath) and removes an attacker-selected outside directory before replacing it with cache metadata. This is distinct from the old template Zip Slip advisory. No malicious archive member is needed, and the PoV disables network access entirely. The bug is in cache-key construction for GitHub…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI Code agent tools fail open without a workspace boundary Summary PraisonAI Code's agent-compatible CODETOOLS wrappers keep a global workspace root initialized to None. If an application uses CODETOOLS, codereadfile, codesearchreplace, or codeapplydiff before calling setworkspace(), the wrappers pass workspace=None into lower-level helpers that only enforce path containment when a workspace is truthy. Absolute paths outside the intended project workspace are then read and modified. The official examples correctly call setworkspace() before CODETOOLS, and this report does not claim configured workspaces are ineffective. The issue is the fail-open default. PraisonAI's security documentation describes workspace boundaries as the path-traversal protection mechanism, and the already-published Python API arbitrary file write advisory (GHSA-hvhp-v2gc-268q) was fixed by defaulting an unset workspace to os.getcwd(). The adjacent read and edit paths reached through CODETOOLS still fail…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unauthenticated PraisonAI UI MCP connect endpoint executes attacker-chosen local commands Summary PraisonAI v4.6.48 exposes the PraisonAIUI MCP client management API through the default UI host apps without authentication. A remote unauthenticated client can send POST /api/mcp/connect with a command and args field. The endpoint passes those values into the MCP stdio client, which starts the attacker-selected local process as the PraisonAI UI service user. The issue is reachable through PraisonAI's hosted UI integration (praisonai ui, praisonai ui agents, praisonai claw, and any app using praisonai.integration.hostapp.createhostapp() / buildhostapp()). praisonai ui and related Typer UI commands bind to 0.0.0.0 by default. Affected Versions Confirmed affected: - praisonai v4.6.48 - Commit tested: d5f1114aaf1a2e9f121a6e66b929149ca2201f1d - Tag tested: v4.6.48 - Pinned UI dependency: aiui==0.3.121 from src/praisonai/uv.lock Likely affected: - Any PraisonAI release that exposes aiui /…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The WhatsApp and Linear bot adapters verify the inbound webhook HMAC signature only when a secret is configured. When the secret environment variable is unset — the default on a fresh install and common in development — verification is skipped entirely and the webhook body is parsed and dispatched as a genuine, trusted event. A remote, unauthenticated attacker who can reach the bot's webhook endpoint can inject arbitrary platform events. Affected code: WhatsApp - src/praisonai/praisonai/bots/whatsapp.py - init (line 108): self.appsecret = appsecret or os.environ.get("WHATSAPPAPPSECRET", "") - defaults to "" - route (line 246): app.router.addpost(self.webhookpath, self.handlewebhook) - default path "/webhook" - handlewebhook (lines 585-595): if self.appsecret: gates the ENTIRE check; when falsy the body is json.loads()'d and dispatched to processwebhookdata() with no verification. Linear - src/praisonai/praisonai/bots/linear.py - init (line 86): self.signingsecret = signingsecret or…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
AgentOS remains unauthenticated after GHSA-pm96 patched version and allows remote agent invocation Summary 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 public AgentOS advisory is published as an instruction-disclosure issue with affected versions < 4.5.128 and patched version 4.5.128. However, v4.5.128, latest release v4.6.57, and current main still register GET /api/agents and POST /api/chat without authentication. 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. Affected Product - Repository: MervinPraison/PraisonAI - Package:…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jobs webhook SSRF protection bypass via DNS rebinding Summary PraisonAI's Async Jobs API validates webhookurl 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, sendwebhook() 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 during webhook delivery. This bypasses the intended SSRF guard in current supported releases. This appears to be an incomplete fix / patch bypass for GHSA-8frj-8q3m-xhgm ("Server-Side Request Forgery via Unvalidated webhookurl in Jobs API"). I defer to maintainers on whether this should be a new advisory/CVE or an amendment to the prior advisory, but current supported…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
praisonai: Jobs API exposes agent-execution endpoints with no authentication Researcher: Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research Target: https://github.com/MervinPraison/PraisonAI --- Package: praisonai on PyPI Affected version (empirically tested): 4.6.48 Components: - praisonai.jobs.server.createapp — praisonai/jobs/server.py - praisonai.jobs.router.createrouter — praisonai/jobs/router.py - Routes mounted at /api/v1/runs/... Weakness: CWE-306 Missing Authentication for Critical Function · CWE-862 Missing Authorization · CWE-94 Code Injection (via prompt / agentyaml). --- TL;DR praisonai ships a standalone async-jobs HTTP server (python -m praisonai.jobs.server --host=0.0.0.0 --port=8005) whose job is to accept job submissions and run agents on the operator's behalf. Every endpoint under /api/v1/runs is unauthenticated. There is no authtoken field, no Depends(verify), no middleware that inspects Authorization — the CORS middleware lists…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
praisonai: recipe serve authentication middleware silently disables itself when no secret is set Researcher: Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research Target: https://github.com/MervinPraison/PraisonAI --- Package: praisonai on PyPI Version tested: 4.6.48. File: praisonai/recipe/serve.py (sha256 491bf8f29e399418260810ba4bf0f6802c6e4aa675628e2be68a9726c15d9b23). --- TL;DR praisonai/recipe/serve.py:312-410 defines two auth middlewares (APIKeyAuthMiddleware, JWTAuthMiddleware). Both contain the same "fail open when the secret is unset" branch at the top of their dispatch: The realistic mis-deploy: 1. operator sets auth: api-key (or auth: jwt) in their recipe YAML, expecting that line alone to enable auth, 2. operator does not set the corresponding apikey: / jwtsecret: value in the same YAML, AND 3. operator does not export PRAISONAIAPIKEY / PRAISONAIJWTSECRET in the environment. The middleware silently treats every request as authenticated and…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unauthenticated Remote Code Execution via Jobs API and Approval Bypass in PraisonAI Summary An unauthenticated attacker can execute arbitrary OS commands on any server running the PraisonAI Jobs API by submitting a crafted workflow YAML. The attack chains two weaknesses: the /api/v1/runs endpoint requires no credentials, and a top-level approve field in the submitted YAML unconditionally bypasses the @requireapproval safety decorator on dangerous tools such as executecommand. Ecosystem: pip | Package: praisonai | Affected: <= 4.6.48 | Patched: (none) --- Details Step 1 — No authentication on the Jobs API POST /api/v1/runs accepts and executes agent jobs from any caller with no token or session required: Compare with the authenticated endpoint in api/agentinvoke.py, which correctly includes Depends(verifytoken). Step 2 — approve YAML field bypasses @requireapproval The YAML parser extracts an attacker-controlled approve list and loads it into a ContextVar that the approval decorator…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated attacker can read arbitrary files on the server by supplying an absolute filesystem path in the agentfile field of the Jobs API. The field has no path validation, no allowlist, and no authentication is required to submit jobs. Details The agentfile field in JobSubmitRequest accepts any filesystem path with no validation: The executor reads the file directly: Proof of Concept Server responds with contents of /etc/passwd. Other exploitable paths: - /proc/1/environ — environment variables, API keys - /home//.ssh/idrsa — SSH private keys - /app/.env — application secrets Impact Any unauthenticated attacker with network access to port 8005 can read any file accessible to the server process, including credentials, private keys, and environment variables.
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Compute-bridged file tools allow shell command injection Summary LocalManagedAgent / SandboxedAgent compute bridging wraps readfile, listfiles, and writefile 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 execute in the container. Affected Product - Repository: MervinPraison/PraisonAI - Package: praisonai - Component: src/praisonai/praisonai/integrations/managedlocal.py - Confirmed affected: - v4.6.10 - v4.6.56 - v4.6.57 - current main at 2f9677abb2ea68eab864ee8b6a828fd0141612e1 - Confirmed not affected: - v4.6.9 - v4.6.1 - v4.5.149 - Suggested affected range: = 4.6.10, <=…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI recipe.runstream() skips dangerous-tool policy enforcement Summary PraisonAI recipe execution blocks default-denied dangerous tools unless the caller explicitly passes allowdangeroustools=True. The normal recipe.run() path enforces this with checktoolpolicy(). The streaming path, recipe.runstream(), loads the same recipe, checks dependencies, and then calls executerecipe() without running the dangerous-tool policy check. As a result, a recipe that honestly declares executecommand in TEMPLATE.yaml requires.tools is denied by recipe.run(), but reaches the execution engine through recipe.runstream() with allowdangeroustools=False. The local PoV uses a harmless printf canary, explicitly unsets PRAISONAIAUTOAPPROVE, and avoids network access. Affected Product - Repository: MervinPraison/PraisonAI - Package: praisonai - Components: - src/praisonai/praisonai/recipe/core.py - src/praisonai/praisonai/recipe/serve.py - src/praisonai/praisonai/cli/features/recipe.py -…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HTTPApproval dashboard renders tool arguments as raw HTML, allowing approval-page XSS to approve dangerous tools Summary 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/{requestid}/decide endpoint, causing HTTPApproval to return approved=True. The local PoV uses a harmless touch /tmp/prai010 command prefix and stops at the approval decision. It does not execute the command. Affected Versions Proposed affected range: = 4.5.2, <= 4.6.57. Validated affected: - current head 2f9677abb2ea68eab864ee8b6a828fd0141612e1 (v4.6.57-4-g2f9677ab) - v4.5.2 - v4.5.3 - v4.5.124 - v4.5.126 - v4.5.128 - v4.6.10 - v4.6.56 - v4.6.57 v4.5.0 and v4.5.1 do not contain the HTTPApproval backend. Impact An attacker who…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI LinearBot processes unsigned webhooks when LINEARWEBHOOKSECRET is missing Summary PraisonAI's LinearBot starts a public webhook listener on 0.0.0.0 and treats LINEARWEBHOOKSECRET as optional. When the secret is absent, startup only logs a warning and handlewebhook() 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 handleagentsession(), and passed into BotSessionManager.chat(). The bot then attempts to post the agent response back to Linear under the configured bot token. The local PoV is offline and deterministic. It does not contact Linear. It calls the webhook handler directly, monkey-patches the outbound Linear comment path, and proves both sides of the boundary: - no secret configured: unsigned forged webhook returns 200, invokes the agent session path once, and attempts…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI dynamic-context artifact tools read arbitrary host files outside artifact storage Summary PraisonAI's Dynamic Context Discovery feature exposes artifact helper tools through ctx.gettools(): The official documentation describes these helpers as a way for the agent to explore large tool-output artifacts that were queued by the middleware: - large tool outputs are saved as artifacts; - the agent receives compact artifact references; and - the agent uses artifacttail and artifactgrep to explore that data. The implemented artifact tools do not enforce that the supplied artifactpath is an artifact created by the configured store or that it lives under the configured artifact base directory. Instead, artifacthead, artifacttail, artifactgrep, and artifactchunk 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 readable by the PraisonAI…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI Slack appmention bypasses configured user/channel authorization Summary PraisonAI's Slack bot applies its configured allowedusers, allowedchannels, and unknown-user pairing policy in the normal Slack message event handler, but not in the adjacent Slack appmention 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.allowedusers; - the channel is not in BotConfig.allowedchannels; - unknownuserpolicy="deny" is configured; and - the same event content is correctly dropped by the normal message handler. This is a sibling-handler guard-coverage issue. Slack documents appmention as a distinct event type rather than a message. event, so deployments subscribed to app mentions can route unauthorized sender input around the guarded message path. Affected product - Repository: MervinPraison/PraisonAI - Package: praisonai - Component:…
Recommended action: Upgrade to 4.6.59 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.