Mervinpraison
Monthly
PraisonAI versions 4.6.10 through 4.6.58 allow shell command injection through its compute-bridged file tools: when a LocalManagedAgent or SandboxedAgent is instantiated with a compute provider attached, the bridge rewrites read_file, list_files and write_file into shell command strings built from raw path arguments, so a crafted path can break out of the quoting and run arbitrary commands on the host (compute="local") or inside the container (Docker). Rated CVSS 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), exploitation needs an authenticated low-privileged actor who can influence a file-tool path argument - for example via prompt injection, a chat endpoint or an automation webhook - and importantly does not require the operator to have granted the critical-marked execute_command tool, so least-privilege tool configurations do not prevent it. The vendor advisory ships a local proof-of-concept reproducer that confirms shell execution through a crafted path; no evidence of active exploitation is provided in the available data, and deployments without an attached compute provider or without the bridged file tools enabled are not affected.
The A2U agent event-stream server shipped with PraisonAI exposes unauthenticated endpoints for any operator who starts the documented `praisonai serve a2u` CLI entrypoint without first setting the A2U_AUTH_TOKEN environment variable, and this gap persists across versions 4.5.115 through 4.6.60 despite the earlier GHSA-f292-66h9-fpmf advisory claiming the unauthenticated-stream issue was fixed in 4.5.115. Remote unauthenticated attackers (CVSS PR:N) who can reach the service - which requires binding to an external interface such as `--host 0.0.0.0`, since the default loopback bind limits exposure to the local host - can subscribe to live agent event streams and read stream metadata, agent responses, tool calls and thinking/progress events, for a confidentiality-only impact rated 7.5. A public local-only PoV script and reproduction output exist in the advisory; that PoV is a harness shim rather than verified working exploit code against a live deployment, and there is no CISA KEV listing or other confirmation of active exploitation. The decisive mitigating control is that pre-setting A2U_AUTH_TOKEN before startup enables the route-level token check and returns 401, making this a config-dependent, default-off authentication gap rather than an unconditionally reachable flaw.
PraisonAI's kernel-enforced SandlockSandbox silently degrades to ordinary subprocess execution when the optional sandlock module imports but reports that Linux Landlock is unavailable, so code that was supposed to be confined can read files outside the configured allowed paths and open network connections even when the native policy was created with network=False. The affected path is code executed through SandboxConfig.native() with SandlockSandbox in the pip package praisonai from 4.5.110 up to (but not including) 4.6.61; the read_file/write_file/list_files helpers still apply safe_sandbox_path checks and are not the exposed surface. CVSS 3.1 scores this 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) because the sandbox escape crosses a security scope with high confidentiality and integrity impact, while the attacker is positioned as a local, low-privileged party able to supply code to the sandbox rather than an unauthenticated network attacker. A public proof-of-concept script ships with the advisory (demonstrated against v4.6.58) that shows both boundary crossings; no confirmed active exploitation (CISA KEV) or public working exploit code is indicated, and the vendor released 4.6.61 as the fix.
PraisonAI recipe execution in versions 4.5.87 through 4.6.60 allows an untrusted steps-based recipe to self-approve the default-denied execute_command shell tool, so an operator who never set allow_dangerous_tools=True can still end up running arbitrary OS commands with the PraisonAI process's privileges. The recipe-level gate (CWE-78/CWE-863) inspects only TEMPLATE.yaml requires.tools, while workflow.yaml agents.*.tools declarations and a top-level approve: list are parsed by YAMLWorkflowParser and installed into the approval registry as already approved. Exploitation is local and user-interaction driven (CVSS 7.8, AV:L/UI:R, PR:N), a public proof-of-value reference exists in the advisory demonstrating the bypass with a harmless printf canary rather than verified working exploit code, and no active exploitation (CISA KEV) is reported for this this_week-priority issue.
Any account holding the lowest 'member' role in a PraisonAI Platform workspace can permanently delete projects, agents, issues, labels, issue dependencies and issue-label attachments created by the workspace owner or by other members, because all six content DELETE endpoints verify workspace membership but never verify resource ownership or an owner/admin role. The flaw affects praisonai-platform from 0.1.4 up to the fix and scores CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/C:N/I:H/A:H), since an authenticated low-privileged user can destroy integrity and availability of workspace content while confidentiality is untouched. Exploitation requires a valid member account inside the targeted workspace - either invited by the victim or obtained through a compromised member credential - so the practical exposure is an insider or account-takeover scenario rather than a mass internet threat; there is no CISA KEV entry, no EPSS signal supplied and no confirmed working exploit package, though the vendor advisory publishes a full step-by-step reproduction.
Unauthenticated remote clients can enumerate the agents deployed on PraisonAI's AgentOS FastAPI surface and invoke them directly, because GET /api/agents and POST /api/chat are registered with no authentication and AgentOSConfig defaults the bind host to 0.0.0.0. This is an incomplete-fix exposure: the previously published patch for GHSA-pm96-6xpr-978x / CVE-2026-40151 (4.5.128) still accepts both no-credential and wrong-bearer requests, as do releases through 4.6.57 and current main, with the advisory's reproducer showing the chat route executing agent.chat() as an observable side effect. PraisonAI 4.6.59 is the version that closes the gap, and the issue is rated act_now because the default configuration puts an agent-control endpoint in reach of any network client, with consequences scaling to whatever tools, memory, private context, API integrations or paid model calls the deployed agents have. A public PoC reference exists in the advisory but is not verified as working exploit code, and no confirmed active exploitation is indicated in the available intelligence.
Server-side request forgery in the PraisonAI Async Jobs API lets an attacker who can submit jobs with a chosen webhook_url steer the server's completion callback into loopback, private-network, or cloud-metadata endpoints, bypassing the webhook guard that current releases do ship. The check is a time-of-check/time-of-use gap: the URL is validated with urlparse() and socket.gethostbyname() at request parsing and again when the Job object is built, but _send_webhook() hands the original hostname to httpx.AsyncClient.post() with no send-time revalidation or IP pinning, so a low-TTL attacker-controlled name can resolve public during validation and internal during delivery. Affected releases are pip packages praisonai from 4.5.126 through 4.6.58; the advisory publishes a local-only PoC that confirms the bypass in-process, but it is not verified as working exploit code against a live deployment, and there is no KEV or active-exploitation signal - consistent with the this_week priority label and an assessed AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N vector where blind SSRF impact depends heavily on what internal services the host can reach and whether they accept POST.
Path traversal in PraisonAI 2.6.0 through 4.6.57 lets an attacker-supplied GitHub template URI write outside the template cache and, once a normal cache entry exists for the same owner/repo/template prefix, delete an attacker-chosen directory via shutil.rmtree. The resolver keeps the user-controlled template path and ref verbatim and the cache layer joins them into ~/.praison/cache/templates/github/<owner>/<repo>/<template>/<ref> without normalization or a boundary check, so a ref such as @../../../../../../outside-target escapes the cache root; nothing triggers unless a user or automated service is induced to load the crafted github: URI (CVSS 3.1 8.1 High, AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H), which is why PraisonAI rates the flaw this_week rather than an emergency. A public PoC reference exists in the GitHub advisory in the form of a local-only reproducer that disables networking; it is not verified as working exploit code, there is no CISA KEV listing, and no EPSS data was supplied. The project patched the issue in 4.6.59.
Unauthenticated remote agent invocation in PraisonAI LinearBot 4.6.56 through 4.6.58: because LINEAR_WEBHOOK_SECRET is treated as optional and defaults to an empty string, the aiohttp webhook listener bound to 0.0.0.0 skips Linear-Signature HMAC verification entirely, so any network caller who can reach the endpoint can POST a forged 'Linear-Event: AgentSession' request that is parsed, backgrounded, and dispatched into BotSessionManager.chat(), causing the bot to run the configured agent and post comments back to Linear under the bot token. Exploitation requires the operator to have started LinearBot with a Linear token but without a webhook secret, and the listener to be reachable; deployments that do set the secret reject missing and invalid signatures with 401 before dispatch. A public proof-of-vulnerability harness exists that exercises the handler offline and monkey-patches the outbound comment path; it is not verified as working exploit code against deployed instances, and there is no confirmed active exploitation (no KEV entry).
Path traversal in PraisonAI's Dynamic Context module lets a caller of the exported agent tools (history_search/history_tail/history_get and terminal_tail/terminal_grep/terminal_commands) supply a run_id that is an absolute path, or an agent_id containing '../', so that the underlying HistoryStore and TerminalLogger build file paths that resolve outside the configured base directory. Versions 3.8.1 through 4.6.58 are affected; the flaw is confidentiality-only and constrained, since readable targets must carry the tool-imposed suffix (.jsonl for history tools, .log for terminal tools) and be readable by the PraisonAI process. The vendor has released 4.6.59, no CISA KEV entry or confirmed active exploitation is reported, and the advisory ships only a local proof-of-value harness that exercises the traversal against an installed package - a public PoC reference exists; it is not verified as remote working exploit code.
Unauthenticated remote agent enumeration and invocation in PraisonAI's AgentTeam.launch() / Agents.launch() HTTP server lets any client that can reach the listening port list deployed agents and trigger agent.chat() calls, burning model resources, reaching connected private context, and firing agent tools and workflow side effects. The affected artifact is the Python package praisonaiagents before 1.6.59, whose FastAPI server binds to 0.0.0.0 by default and accepts requests with no Authorization header - or even with an obviously wrong bearer token. Vendor-released patch: praisonaiagents 1.6.59 (PraisonAI v4.6.59); no public exploit identified at time of analysis, and the practical limiting factor is deployment: the routes are only remotely reachable if launch() is actually started and network-exposed rather than bound to localhost or placed behind an authenticating proxy.
Server-side request forgery in the SearxNG-backed search tools shipped with the praisonaiagents Python package before 1.6.62 lets prompt-injected content hijack the agent's outbound HTTP requests and read the responses back into the model's context, enabling internal service and API disclosure plus internal host/port enumeration. The vulnerable sink is the LLM-exposed searxng_url tool parameter, which is forwarded to requests.get() without any validation of scheme, host, port, or resolved address; search_web and searxng_search are part of the default agent tool profile, so any agent that ingests attacker-controlled web pages, files, or upstream tool output is in scope. The CVSS vector is AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:L (8.8) - no authentication is needed (PR:N), but exploitation depends on the agent actually processing malicious content and the model complying with the injected tool call (UI:R); confidential impact is high while integrity and availability impact are low. No public exploit identified at time of analysis; in cloud deployments the same primitive can reach the instance metadata endpoint (169.254.169.254) and potentially expose IAM credentials, though that requires the instance metadata service to be reachable from the agent's network position.
Authentication bypass in praisonai-platform before 0.1.6 lets any remote unauthenticated attacker mint a valid HS256 JSON Web Token and impersonate arbitrary users against protected API routes. The flaw is a hardcoded fallback signing secret ('dev-secret-change-me') combined with a production guard that never fires when the operator leaves both PLATFORM_JWT_SECRET and PLATFORM_ENV unset - the common mis-deploy - so the platform silently starts signing tokens with a publicly known literal drawn straight from the source code. CVSS 3.1 scores this 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and EPSS is 0.51% (42nd percentile); there is no CISA KEV listing and no public exploit identified at time of analysis, though exploitation requires nothing more than a forged token and no authentication whatsoever.
Unauthenticated authentication bypass in praisonai-platform prior to 0.1.6 (and PraisonAI before 4.6.51) allows a remote attacker to forge HS256 session JWTs using the publicly known default signing key 'dev-secret-change-me' and be accepted as any identity the attacker names in the token's sub claim, including a workspace owner. The vulnerable state is the shipped default: the documented startup command sets neither PLATFORM_JWT_SECRET (so the hardcoded fallback is used) nor PLATFORM_ENV (which stays at 'dev', leaving the startup and token-issuance guards default-open). CVSS 3.1 scores this 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), consistent with an unauthenticated full-compromise primitive; EPSS is low at 0.53% (43rd percentile), no public exploit code was identified at time of analysis, and there is no CISA KEV listing, although the flaw is trivially exploitable against default deployments and the only practical constraint is that workspace-owner takeover requires knowing the target owner's user/sub identifier.
PraisonAI's TypeScript MCP server (npm package `praisonai`, versions 1.5.0 through 1.7.1) exposes an HTTP JSON-RPC transport that performs no authentication or authorization, so any network client that can reach the listening port can call tools/call, resources/read, or prompts/get and trigger registered handlers with the server process's credentials and privileges. The server's startHttp() binds the unspecified address (all interfaces) with no host restriction and ignores the Authorization header entirely; the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8) confirms this is unauthenticated and remotely reachable, though exploitation requires the operator to have enabled the HTTP transport and made the port network-reachable. Publicly available exploit code exists (a public gist), but there is no evidence of confirmed active exploitation, and the EPSS score is low at 0.64% (49th percentile); the vendor-released fix is version 1.7.2.
Arbitrary command execution in the npm TypeScript package praisonai (versions 1.5.1 through 1.7.1) allows an attacker who can influence the string passed to the exported shell() helper to break out of its read-only allowlist by prefixing an approved command and appending a second one with shell chaining syntax such as 'echo ok; <payload>'. Because utility-tools.ts validates only the first whitespace-delimited token and then hands the complete original string to Node's child_process.exec(), the injected command runs with the PraisonAI process privileges. The flaw is fixed in 1.7.2; the advisory includes a deterministic local proof-of-value, and there is no CISA KEV listing or EPSS data indicating active exploitation at time of analysis.
The npm package praisonai exposes a SandboxExecutor 'network-isolated' mode that is advertised to users as 'No network access (proxy blocked)' but only injects http_proxy/https_proxy=http://localhost:0 without creating any operating-system network boundary, so sandboxed commands that ignore proxy environment variables can still open sockets directly. Versions 1.2.3 through 1.7.1 of the npm package are affected; an initial fix shipped in 1.7.2. A local-only proof-of-concept is described in the vendor advisory (a plain Node HTTP client reaches a loopback server while a proxy
Let me synthesize. Key facts: - CVE-2026-57134, PraisonAI (npm package "praisonai", TypeScript MCP security helper). - MCPSecurity.evaluatePolicy() only validates credentials for api-key/bearer; basic/oauth accept any non-empty Authorization header, skipping validate() callback, returning authenticated: true. - Affected: npm praisonai >= 1.5.1, <= 1.7.1; fixed in 1.7.2. CPE cpe:2.3:a:mervinpraison:praisonai:*:*:*:*:*:*:*:* - CVSS 8.2 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. But logically, exploitation requires the deployment to use basic or oauth auth policy — that's a configuration prerequisite. Hmm. CVSS PR:N given. My assessed vector: I'd argue PR:N is defensible from the attacker's perspective (attacker sends an arbitrary Authorization header without valid credentials). But the configuration requirement: the target must use basic/oauth policy. AV:N is fine. AC:L? Arguably AC:H because it requires non-default config (basic/oauth policy configured). Let me think: the guidance says choose PR honestly — if exploitation requires control over configuration files, admin access, or authentication, use PR:H or PR:L. Here the attacker doesn't need config access; they need the target to have configured basic or oauth. That's a configuration precondition, not attacker privilege. I'd keep PR:N and use AC:H? Hmm. Many would keep AC:L. Actually the exploit is trivially automatable once the target uses basic/oauth. I'll go AC:L, PR:N, but note the pre-condition. Hmm, but the rubric's example: "Requires write access to the httpd configuration, so PR:H and AC:H". That's different. Here attacker just sends header. I'll use AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N — matching but I should express independent judgment. Maybe I could argue I:L and A:N as given. Let me consider C:H — access to MCP tools and resources protected by policies → confidentiality high, integrity low. That's reasonable. I'll go with AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N — but then it's a copy. The instruction says "NOT
Code escaping sandbox in the PraisonAI npm package's built-in codeMode tool (praisonai 1.4.0 through 1.7.1) lets anyone who can influence the code string read host files, write or modify files, spawn subprocesses, and consume host process resources, despite the tool advertising a sandbox boundary. The implementation blocks a handful of literal source patterns and shadows process and require with undefined properties, but untrusted code can walk the JavaScript prototype chain (for example ({}).constructor.constructor) to recover the real Function constructor and reach process.mainModule.require, bypassing both controls at low complexity. The vulnerability is rated 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) with the vector indicating some prior privilege or context is needed to reach the tool; EPSS is low (0.65%, 49th percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis, but the low attack complexity and high confidentiality, integrity, and availability impact make this a genuine high-priority fix rather than an inflated score.
Ar
Unauthenticated MCP tool invocation in PraisonAI (praisonaiagents 0.6.0–1.6.58 and praisonai 3.10.0–4.6.58) lets a malicious website use DNS rebinding to reach a local or internal ToolsMCPServer SSE endpoint on /sse and /messages/, enumerate registered tools, and invoke them with the server user's privileges. The legacy SSE wrapper performs no Host, Origin, or authentication enforcement, while the newer Streamable HTTP transport rejects the same hostile Origin with HTTP 403, isolating the flaw to the legacy SSE path. An initial remediation ships in praisonaiagents
PraisonAI deployments that opt out of authentication by setting PRAISONAI_CALL_AUTH=disabled expose the /api/v1/
PraisonAI's optional standalone async-jobs HTTP server can be driven by any unauthenticated network client that can reach its listener, which binds 0.0.0.0:8005 by default, because every route under /api/v1/runs lacks authentication and per-job ownership checks. An attacker can submit jobs carrying attacker-controlled prompts and agent YAML/configuration, causing the operator's process to execute agents with access to its environment variables, service credentials, and connected tool capabilities, and can also list, read, stream, cancel, or delete any job system-wide. Rated CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), with publicly available exploit code exists per SSVC exploitation: poc, an EPSS of 0.97% (60th percentile), and no CISA KEV listing; the vendor has published patched releases.
PraisonAI's WhatsApp and Linear bot webhook handlers fail open when their shared-secret environment variables are unset: HMAC signature verification is skipped entirely and the raw JSON body is parsed and dispatched as a trusted platform event. Any remote client that can reach the bot's webhook route (default /webhook) can forge WhatsApp messages or Linear AgentSession/Comment events without authentication, impersonating platform users and injecting attacker-controlled content into agent prompts and actions. The flaw affects releases before 4.6.59, is trivially automatable with a single unsigned HTTP POST, and no public exploit code or active exploitation has been identified at time of analysis.
Authentication bypass in PraisonAI's `recipe serve` command: when an operator selects `auth: api-key` or `auth: jwt` in a recipe YAML but omits the matching `api_key:`/`jwt_secret:` value and does not export PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET, APIKeyAuthMiddleware and JWTAuthMiddleware take a fail-open branch and forward every non-`/health` request unauthenticated to the recipe execution, input, and output surfaces, potentially triggering connected tools. Remote unauthenticated attackers who can reach an exposed recipe-serve endpoint (CVSS:3.1/AV:N/PR:N/UI:N) can therefore act as if authenticated, though independent analysis raises attack complexity to AC:H because the rawe 9.8 vendor score only manifests under a specific operator mis-deployment - the fail-open does not occur when the secret is set or when authentication was never enabled. Publicly available exploit code exists per the SSVC exploitation signal (poc), EPSS is 0.90% (58th percentile), and the issue is not listed in CISA KEV; it is fixed in 4.6.58.
Path traversal in PraisonAI before 4.6.59 allows prompt-influenced calls to code agent tools to read and modify arbitrary files outside any intended project boundary when an application exposes CODE_TOOLS, code_read_file, code_search_replace, or code_apply_diff before calling set_workspace(). The global _workspace_root defaults to None, and the lower-level file helpers silently skip path containment checks when workspace is falsy - a fail-open design identical to a previously patched write_file path (GHSA-hvhp-v2gc-268q). A proof-of-concept exists per SSVC data; no confirmed active exploitation in CISA KEV.
Unauthenticated path traversal in PraisonAI's Jobs API (versions prior to 4.6.59) allows any remote caller to read arbitrary files on the server. The `agent_file` field in `POST /api/v1/runs` accepts absolute or directory-traversing filesystem paths with no validation, allowlist, or authentication gate; the executor passes the value directly to `yaml.safe_load(open(agent_file))`. An attacker with network access to port 8005 can exfiltrate credentials, SSH private keys, environment variables, and any file readable by the service account. A working proof-of-concept is publicly available in the GitHub security advisory GHSA-p4pj-vh7h-6cqh.
Server-Side Request Forgery in PraisonAI's multi-agent web tooling allows an authenticated user to exfiltrate internal service responses by supplying a hostname whose DNS A record resolves to a loopback, RFC-1918, link-local, or cloud-metadata address. The SSRF guard in `SpiderTools._validate_url` → `_host_is_blocked` inspects only literal IP encodings and silently falls through for any DNS hostname, meaning a static internal A record is sufficient - no DNS rebinding race is required. Affected are praisonaiagents versions up to 1.6.48 (per GHSA) across the `scrape_page`, `crawl`, `extract_links`, `extract_text`, and `@url` mention-fetch surfaces; the fix ships in praisonaiagents 1.6.58/1.6.59 and PraisonAI 4.6.58. No public exploit identified at time of analysis, though SSVC notes a proof-of-concept exists.
IMAP command injection in the PraisonAI praisonaiagents email tools before 1.6.59 lets LLM-controlled arguments (from_addr, subject, query, message_id) break out of quoted IMAP SEARCH criteria and inject arbitrary IMAP commands, giving access to, modification of, or deletion of mailbox data. Exploitation requires an agent deployed with email credentials configured (EMAIL_ADDRESS and EMAIL_PASSWORD) and with the search_emails, reply_email, or archive_email tools exposed, plus an attacker able to steer the tool-call arguments — typically via crafted or indirect prompt injection reaching the agent. The advisory includes a static proof-of-concept data-flow trace, and CISA's SSVC assessment records exploitation status as 'poc'; the flaw is not listed in CISA KEV, and no EPSS score was supplied.
WebSocket origin-validation bypass in PraisonAI's Browser Server (praisonai/browser/server.py) before 4.6.58 lets an attacker forge a Chrome-extension Origin header and drive connected browser extensions. The check uses re.match() against the unanchored pattern chrome-extension://[a-z0-9]{32}, so any Origin with 32+ trailing characters is accepted before websocket.accept(), after which start_session commands trigger arbitrary browser automation, cookie theft, and screenshot capture. This is a patch bypass of CVE-2026-40289 (GHSA-8x8f-54wf-vv92); a working PoC is published in the advisory, though it is not in CISA KEV - no public exploit weaponization beyond the advisory PoC is identified.
Cross-site request forgery against the PraisonAI MCP HTTP-stream transport allows unauthenticated remote attackers to execute arbitrary MCP tools on a developer's local machine when a victim visits a malicious webpage. The attack is enabled by a flawed prefix-match origin check (`startswith`) in versions prior to 4.6.58 that accepts `http://localhost.attacker.com` as a valid localhost origin, and is further facilitated by the absence of a default API key and the CORS simple-request mechanism (Content-Type: text/plain) that bypasses browser preflight. The highest-impact consequence is persistent prompt injection: a forged request can write attacker-controlled agent instruction files that the runtime loads on every subsequent agent run. No public exploit is identified at time of analysis; vendor-released patch 4.6.58 is confirmed.
Authentication fail-open in PraisonAI's Recipe HTTP server allows unauthenticated remote attackers to invoke recipe execution endpoints despite authentication being nominally enabled. Versions prior to 4.6.58 of the pip package are affected: when the server is started with --auth api-key or --auth jwt but the corresponding PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET environment variable is absent, create_auth_middleware() silently bypasses all authentication checks. The CLI safety check that blocks external binding only verifies auth mode is not 'none', failing to detect this secret-absent misconfiguration, leaving POST /v1/recipes/run, /v1/recipes/stream, and /v1/recipes endpoints fully open to unauthenticated callers. No active exploitation is confirmed (not in CISA KEV); vendor-released patch is available in v4.6.58.
Path traversal in praisonaiagents prior to 1.6.58 allows a low-privileged caller to write arbitrary JSON files to any process-writable filesystem location by supplying a crafted user_id containing ../ sequences to the FileMemory constructor. All versions of the praisonaiagents pip package below 1.6.58 are affected; the vulnerability exists in the core library's FileMemory class, not an example or optional component. A detailed proof-of-concept is included in the GitHub Security Advisory (GHSA-gxmw-5f7x-6g22), and no public exploit identified at time of analysis beyond that PoC; no CISA KEV listing exists.
PraisonAI's `praisonai serve` subsystem (agents and unified modes) accepts an `--api-key` CLI flag that is parsed but never wired into the underlying FastAPI application, leaving POST /agents, POST /agents/{name}, and POST /api/v1/agents/{id}/invoke fully unauthenticated regardless of any key configured by the operator. All versions prior to 4.6.58 are affected, with the flaw present since approximately 4.6.34 when the serve subsystem first shipped. A public proof-of-concept exists per the GHSA advisory; no public exploit identified at time of analysis in CISA KEV, but the zero-authentication network attack surface makes this a high-priority fix for any deployment exposing the serve interface to untrusted networks.
Unauthenticated remote agent invocation in PraisonAI versions 4.6.34 through 4.6.57 allows any network-reachable caller to execute configured agents via POST /agents and POST /agents/{agent_name} despite an operator-supplied --api-key. The FastAPI app created by _create_agents_app() accepts the key at the CLI layer but never applies it as middleware or a route dependency, rendering the documented authentication control entirely inert on those endpoints. A proof-of-concept is included in GHSA-7ww9-85pg-cv4x, and the flaw is fixed in v4.6.58 via an _authorise_request() method that enforces Bearer or X-Auth-Token header validation.
SSRF protection bypass in PraisonAI's praisonaiagents library (all versions before 1.6.58) lets low-privileged users route agent web-fetching functions to internal HTTP services by supplying hostnames - such as 127.0.0.1.nip.io - that pass the static IP blocklist in spider_tools._host_is_blocked() because the function never performs DNS resolution before validation. The affected functions scrape_page, extract_links, crawl, and extract_text are registered as default LLM-callable agent tools, so any agent prompted to retrieve a user-supplied URL will trigger this path; a live proof-of-concept is documented in the GitHub Security Advisory (GHSA-x44h-65qv-cw74), confirming that publicly available exploit code exists. The CVSS scope change (S:C) and high confidentiality impact (C:H) reflect real ability to exfiltrate responses from internal services such as cloud metadata endpoints or localhost-bound APIs.
Authentication bypass in PraisonAI's AgentServer component exposes all routes - /publish, /events, /info, /health - to unauthenticated remote callers, even when operators have explicitly configured an auth_token in ServerConfig. The AgentServer._create_app factory never reads or enforces the configured token, rendering it dead code while /info actively misleads operators by displaying it as masked ('***'), creating a false sense of security. No public exploit code has been identified at time of analysis, and it is not listed in CISA KEV; the fix is confirmed in praisonaiagents 1.6.58.
Server-side request forgery in PraisonAI's web_crawl() function (versions 1.5.128-1.6.57) allows an attacker who can influence URLs processed by agent or tool workflows to exfiltrate responses from internal services, private network hosts, and cloud metadata endpoints such as AWS IAM credential URLs. This is a confirmed patch bypass of the previously disclosed SSRF class in CVE-2026-40160 and GHSA-8f4v-xfm9-3244, exploiting the fact that the httpx fallback client uses follow_redirects=True without revalidating redirect destinations against the original host blocklist. No public exploit code and no CISA KEV active exploitation designation have been identified at time of analysis.
Arbitrary Python code execution in PraisonAI's workflow include feature allows an attacker who controls a local recipe directory to execute arbitrary code as the PraisonAI process user. Affected are praisonai 3.9.26-4.6.57 and praisonaiagents 0.12.12-1.6.57. This is a hardening bypass: the vulnerable sink in Workflow._execute_include() skips the PRAISONAI_ALLOW_TEMPLATE_TOOLS/PRAISONAI_ALLOW_LOCAL_TOOLS opt-in gates and the centralized safe loader that protect all other tools.py autoload paths, making it a distinct variant within an established advisory family. No public exploit or CISA KEV listing has been identified at time of analysis.
Unauthenticated remote command execution in PraisonAI's bundled Claude GitHub Actions workflow (versions before 4.6.40) lets an outside contributor run arbitrary shell code on the CI runner by opening a fork pull request whose branch name contains shell metacharacters and posting an @claude comment. Two compounding flaws enable this: the workflow interpolates the attacker-controlled branch name directly into an unquoted Bash run: block, and it triggers for any @claude comment without verifying the commenter is a trusted collaborator. Because the job runs with a GitHub App token holding write permissions plus OIDC and gh/git access, injected commands can be chained via $GITHUB_PATH into later privileged steps to gain repository write, PR/issue manipulation, or OIDC-token abuse. No public exploit identified at time of analysis.
Arbitrary code execution in PraisonAI (praisonaiagents) before 1.6.78 lets an attacker who can drop a Python file into a plugin directory run their own code. The plugin manager auto-discovers and executes any .py file found in project-level or user-home .praisonai/plugins/ directories at initialization, with no code signing, integrity checks, or sandboxing. VulnCheck reported it under CWE-94; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Path-traversal remote code execution in PraisonAI (mervinpraison/praisonai) before 1.6.78 lets an authenticated agent user abuse SkillTools.run_skill_script(), which executes skill scripts without validating that the supplied path stays inside the intended working directory. Because absolute file paths are accepted, a low-privileged attacker can point the skill runner at any executable script on the host and run it. No public exploit code has been identified and it is not in CISA KEV, but the flaw was reported by VulnCheck and a GitHub Security Advisory (GHSA-c44f-37qr-gw3f) confirms the fix.
Broken authorization in PraisonAI Platform before 0.1.9 lets any authenticated workspace member modify shared label taxonomy and issue-label associations they should not control, renaming and recoloring shared labels and adding or removing labels on issues created by owners or admins. The flaw (CWE-862, missing authorization) stems from label PATCH and issue-label POST/DELETE endpoints trusting workspace membership without enforcing owner/admin role checks. Reported by VulnCheck with a vendor patch available; there is no public exploit identified at time of analysis and it is not in CISA KEV.
OS command execution in PraisonAI before 4.6.78 lets an attacker who can supply a workflow definition escape the inline-Python sandbox and run arbitrary shell commands with the privileges of the agent process. The flaw lives in JobWorkflowExecutor._exec_inline_python(), whose AST-based validation fails to reject `import os` followed by `os.system()`, turning a malicious YAML workflow file into RCE. No public exploit code or CISA KEV listing is identified at time of analysis, though the bypass technique is described in detail in the vendor advisory.
Webhook signature-verification bypass in PraisonAI before 4.6.78 lets unauthenticated attackers forge Svix 'message.received' events when the framework runs in AgentMail webhook mode. Because incoming payloads are trusted without validating the Svix signature (CWE-287), an attacker can POST crafted JSON to the webhook endpoint and cause configured agents to process attacker-chosen sender addresses and message bodies. A vendor patch exists (4.6.78); there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Authentication bypass in PraisonAI before 4.6.78 lets a remote, unauthenticated attacker reach the Call API agent-invocation endpoints when the deployment runs with PRAISONAI_CALL_AUTH=disabled. Because the localhost-only safeguard derives the bind host from the client-supplied HTTP Host header, an attacker on the network can send a spoofed 'Host: 127.0.0.1' header to defeat the restriction and both enumerate and invoke registered agents. Vendor patch is available (reported by VulnCheck); no public exploit identified at time of analysis and it is not listed in CISA KEV.
Code injection in PraisonAI before 4.6.78 lets attackers who control deployment configuration achieve arbitrary Python execution because the API-server deployment generator fails to safely encode the deploy.api.host and agents_file values before emitting them into generated Python source (CWE-94). Injected expressions run when the generated API server starts or handles requests, yielding full code execution in the server process. No public exploit is identified at time of analysis; the flaw was reported by VulnCheck and a vendor patch is available.
Server-side request forgery in PraisonAI's web_crawl tool (versions before 1.6.78) allows an authenticated attacker to reach internal HTTP services and exfiltrate their response bodies. The flaw stems from a time-of-check/time-of-use gap: hostnames are validated once but re-resolved at connection time without IP pinning, so DNS rebinding defeats the SSRF allowlist. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the technique is well-documented and the vendor has released a fix in 1.6.78.
Security-policy bypass in PraisonAI before 4.6.78 renders the default Subprocess Sandbox backend inert, so administrator-defined blocked_commands, blocked_paths, blocked_imports, allow_subprocess, and allow_file_write restrictions are silently ignored. Any actor able to feed instructions into a PraisonAI agent can execute arbitrary subprocess commands, read sensitive files, and perform destructive file operations even though an explicit deny policy is configured. Reported by VulnCheck with a CVSS 4.0 base score of 8.7; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Remote code execution in PraisonAI before 1.6.78 allows attackers to run arbitrary Python on the host by manipulating the LLM that drives the CodeAgent component. Because CodeAgent._execute_python() runs LLM-generated code with no AST validation, import restrictions, or sandbox, an attacker who can shape model output via prompt injection can exfiltrate all environment secrets and gain full control of the agent host. VulnCheck reports the flaw with a maximum CVSS 4.0 score of 10.0; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Root-level command execution and arbitrary file write in PraisonAI's AICoder component (all versions before 4.6.78) let an attacker with chat-interface access weaponize LLM tool calls: because file paths are not validated and shell commands are not sanitized, a crafted prompt can write files anywhere on the host and run arbitrary shell commands as root. Reported by VulnCheck and fixed in 4.6.78, this is a CVSS 9.4 (v4.0) flaw with no public exploit identified at time of analysis, though the injection path is trivial to trigger for any user who can reach the chat.
Broken authorization in PraisonAI Platform (praisonai-platform) before 0.1.9 lets any low-privileged workspace member modify owner- or admin-created projects, issues, and agents because the PATCH routes only check for workspace-member role instead of owner/admin. Because a member can reassign a project's lead_id to their own user id, they can then satisfy and bypass the delete route's owner/admin check to destroy owner-created projects. No public exploit identified at time of analysis, though the flaw is trivially reachable by any authenticated tenant member.
System prompt extraction and unauthorized tool invocation in PraisonAI before 4.6.78 arise because the prompt-injection defense ships with its blocking threshold defaulting to CRITICAL, so HIGH-severity injection attempts are detected and logged but never blocked. Any remote user interacting with a PraisonAI agent can submit single-vector prompt injection (instruction overrides, financial manipulation) that scores HIGH and passes through, leaking the system prompt and triggering agent tools without authorization. No public exploit identified at time of analysis, and the issue is not in CISA KEV; the vendor CVSS 4.0 score is 8.7 (High).
Server-side request forgery in PraisonAI's Crawl4AI/Chromium crawling backend (all versions before 1.6.78) lets low-privileged users bypass URL allowlist/SSRF validation through DNS rebinding and HTTP redirects, causing the headless browser to reach internal-only services and return their responses. Because validation happens before the browser dereferences the URL, an attacker-controlled host can pass the check and then resolve or redirect to internal endpoints, exposing sensitive internal data (demonstrated with canary values). Reported by VulnCheck; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Unauthenticated agent access in PraisonAI before 1.7.3 lets remote attackers read agent instructions and system prompts and directly invoke agents because the server ships with insecure defaults - binding to all network interfaces (0.0.0.0), enforcing no API key, and allowing wildcard CORS. Any attacker who can reach the service can call GET /api/agents to exfiltrate proprietary prompt logic or POST /api/chat to abuse the agents without credentials. There is no public exploit identified at time of analysis, but exploitation is trivial and requires no special tooling given the missing authentication.
SQL/CQL injection in PraisonAI's PGVector and Cassandra knowledge-store backends before 4.6.78 allows a caller who controls the create_collection() dimension argument to inject arbitrary database tokens. Although the code validates schema, keyspace, and collection-name identifiers, the dimension value - typed as int but never enforced at runtime - is string-interpolated directly into the vector column of the generated CREATE TABLE DDL, so a payload like '3); DROP TABLE tenant_secrets; --' executes against the backing database. No public exploit identified at time of analysis; the flaw was reported by VulnCheck and a vendor patch is available.
Remote code execution in PraisonAI before 4.6.78 lets an attacker who can supply the agents_file parameter to deploy/api.py run arbitrary Python, because that value is interpolated directly into an f-string that is later executed as generated server code via subprocess.Popen(). The CVSS 4.0 base score is 9.4 and the vector requires high privileges (PR:H), meaning the attacker must already be able to reach and drive the deployment API. No public exploit has been identified at time of analysis and it is not on the CISA KEV list.
Broken authorization in PraisonAI Platform before 0.1.9 lets an authenticated workspace member delete owner-created issue dependencies they should not be able to remove. The DELETE dependency route accepts either endpoint of a dependency edge and validates delete permission only against the caller-supplied issue URL, so a member blocked (403) via the owner's issue endpoint can delete the same edge by targeting their own member-owned issue endpoint. Reported by VulnCheck with a vendor patch available; no public exploit identified at time of analysis and it is not on CISA KEV.
Arbitrary Python code execution in PraisonAI (praisonaiagents) before 1.6.78 occurs when AgentFlow._resolve_pydantic_class resolves a string output_pydantic reference in a workflow step, causing the framework to import a sibling tools.py from the workflow file's directory via importlib exec_module without any sandboxing. Because this loader ignores the PRAISONAI_ALLOW_*_TOOLS environment guardrails, an attacker who supplies a malicious workflow file plus its tools.py runs code with the workflow runner's privileges the moment the workflow is executed via WorkflowManager or loaded through load_yaml. No public exploit is identified at time of analysis, and the flaw is not listed in CISA KEV.
Command execution allowlist bypass in PraisonAI before 4.6.78 lets a low-privileged attacker who can supply commands to the framework's restricted-execution feature slip past its shell-metacharacter filters by abusing find's built-in -exec, -execdir, and -delete actions. Because those actions run binaries and delete files entirely inside the find process, they never trip the metacharacter allowlist, so the attacker can read blocked files, delete arbitrary files, and launch non-allowlisted binaries. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the CVSS 4.0 base score of 8.7 (High) reflects full loss of confidentiality, integrity, and availability of the affected system.
GitHub Actions credential leakage in PraisonAI through ArtiPACKED attack exposes GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN in workflow artifacts. Versions 4.5.139 and below persist credentials in .git/config via actions/checkout without disabling persist-credentials, allowing any user with read access to public repository artifacts to extract tokens and compromise the supply chain. CVSS 9.1 (Critical) with network-accessible, unauthenticated attack vector. EPSS data not provided; no confirmed active exploitation (KEV status not indicated), but attack technique is publicly documented by Palo Alto Unit42 and widely reported. Vendor-released patch available in version 4.5.140.
Unauthenticated remote session hijacking in PraisonAI's browser bridge (versions <4.5.139) and praisonaiagents (<1.5.140) allows network attackers to control browser automation sessions without authentication. The /ws WebSocket endpoint accepts connections from any client omitting the Origin header, enabling attackers to send start_session commands that hijack idle browser-extension sessions and receive all automation outputs. With CVSS 9.1 (Critical) scoring driven by network attack vector, low complexity, and no authentication requirement (AV:N/AC:L/PR:N), this represents a severe risk in any deployment where the default 0.0.0.0 binding exposes the service to untrusted networks. No public exploit identified at time of analysis, though exploitation requires only basic WebSocket client capabilities.
Arbitrary command and code execution in PraisonAI's workflow engine (versions <4.5.139) and praisonaiagents (<1.5.140) allows remote unauthenticated attackers to execute shell commands and Python code through malicious YAML workflow files. The vulnerability stems from unsafe processing of 'run:', 'script:', and 'python:' directives in job-type workflows without validation or sandboxing. With a critical CVSS score of 9.8 and network-accessible attack vector requiring no privileges or user interac
Arbitrary Python code execution in PraisonAI ≤4.5.138 occurs when malicious tools.py files are automatically imported from the current working directory without validation. Attackers placing a crafted tools.py in shared projects, cloned repositories, or writable workspaces achieve immediate code execution with full process privileges upon PraisonAI startup. EPSS data not available, but the local attack vector (AV:L) requiring no privileges (PR:N) or user interaction (UI:N) enables exploitation through supply chain and workspace poisoning attacks. No public exploit identified at time of analysis, though the vulnerability is trivial to exploit given the straightforward code injection mechanism.
SQL identifier injection in PraisonAI's SQLiteConversationStore allows authenticated local attackers with configuration control to extract database schema and manipulate query results. The vulnerability affects PraisonAI versions prior to 4.5.133, where unsanitized table_prefix values are concatenated into SQL queries via f-strings. Attackers controlling configuration inputs (from_yaml/from_dict) can inject SQL fragments to access internal SQLite tables like sqlite_master and execute UNION-based injections. A vendor patch is available in version 4.5.133. No public exploit code or active exploitation confirmed at time of analysis. CVSS 7.2 indicates local attack vector with low complexity but requires low privileges and present attack complexity conditions.
Server-Side Request Forgery (SSRF) in PraisonAIAgents versions prior to 1.5.128 allows unauthenticated attackers to manipulate LLM agents into crawling arbitrary internal URLs. The httpx fallback crawler accepts user-supplied URLs without host validation and follows redirects, enabling access to cloud metadata endpoints (169.254.169.254), internal services, and localhost. Response content is returned to the agent and may be exposed in attacker-visible output. This vulnerability is the default behavior on fresh installations without Tavily API keys or Crawl4AI dependencies. No public exploit identified at time of analysis.
Arbitrary code execution in PraisonAI multi-agent system (<4.5.128) via Python sandbox escape. Incomplete AST attribute filtering allows type.__getattribute__ trampoline to bypass restrictions on __subclasses__, __globals__, and __bases__, enabling untrusted agent code to break containment. Attack requires local access and user interaction to execute malicious code. No public exploit identified at time of analysis.
Path traversal in PraisonAI multi-agent teams system (versions prior to 4.5.128) enables arbitrary file overwrite through malicious .praison archive bundles. The cmd_unpack function in recipe CLI performs unvalidated tar extraction, allowing attackers to embed ../ path sequences that escape the intended extraction directory. Unauthenticated attackers can distribute weaponized bundles that, when unpacked by victims via 'praisonai recipe unpack' command, overwrite critical system files with attacker-controlled content. No public exploit identified at time of analysis.
Arbitrary code execution occurs in PraisonAI (all versions prior to 4.5.128) when a malicious tools.py file exists in the working directory. The framework automatically imports and executes this file during startup without validation or user consent, enabling unauthenticated local attackers to execute arbitrary Python code by placing a weaponized tools.py in directories accessed by users or CI/CD pipelines. User interaction is required (running praisonai command). No public exploit identified at time of analysis.
Environment variable exfiltration in PraisonAIAgents versions prior to 1.5.128 allows unauthenticated remote attackers to steal secrets (database credentials, API keys, cloud access keys) through shell_tools.py execute_command function. The vulnerability leverages deceptive command approval where unexpanded $VAR references shown to human reviewers differ from executed commands containing expanded environment variable values. Requires user interaction. No public exploit identified at time of analysis.
Server-side request forgery in PraisonAIAgents multi-agent system allows authenticated attackers to force internal network reconnaissance and data exfiltration through unvalidated URL crawling. The web_crawl() function in versions prior to 1.5.128 accepts arbitrary URLs from AI agents without scheme allowlisting, hostname blocking, or private network checks, enabling access to cloud metadata endpoints (AWS/Azure/GCP), internal services, and local filesystems via file:// URIs. Exploitation requires low-privileged authenticated access with network reachability and no user interaction. No public exploit identified at time of analysis.
Unauthenticated modification of the tool approval allowlist in PraisonAI multi-agent system (versions prior to 4.5.128) enables attackers to bypass human-in-the-loop safety controls by injecting dangerous tool names (shell_exec, file_write) into the allowlist via the /api/approval/allow-list gateway endpoint. The ExecApprovalManager then auto-approves agent invocations of these tools, circumventing the approval mechanism's core security function. Attack requires local access; no public exploit identified at time of analysis. CVSS 7.9 reflects high integrity impact with scope change due to compromised safety boundaries in agent workflows.
Unauthenticated resource exhaustion in PraisonAI versions prior to 4.5.128 allows remote attackers to drain OpenAI API credits and exhaust server resources. The /media-stream WebSocket endpoint in the call module accepts connections without authentication or Twilio signature validation, enabling unlimited concurrent sessions to OpenAI's Realtime API using the server's credentials. No public exploit identified at time of analysis. Affects PraisonAI deployments exposing the call module's WebSocket interface.
Server-Side Request Forgery in PraisonAI versions prior to 4.5.128 allows unauthenticated remote attackers to force the server to send HTTP POST requests to arbitrary internal or external destinations via an unvalidated webhook_url parameter in the /api/v1/runs endpoint. Attackers can abuse this to access cloud metadata services (AWS/GCP/Azure instance metadata), internal APIs, and network-adjacent services, potentially exposing credentials, configuration data, or triggering unauthorized actions. No public exploit identified at time of analysis. CVSS 7.2 indicates changed scope with low confidentiality and integrity impact.
Environment variable injection in PraisonAI deploy.py (versions prior to 4.5.128) allows authenticated local attackers to inject arbitrary environment variables into Google Cloud Run services during deployment. The vulnerability stems from improper validation of comma-separated gcloud CLI arguments, enabling attackers to manipulate openai_model, openai_key, or openai_base parameters with embedded commas, causing gcloud to parse injected content as additional KEY=VALUE pairs. This grants high-level access to confidential service configuration and permits unauthorized modifications. No public exploit identified at time of analysis.
Command injection in PraisonAIAgents memory hooks executor allows authenticated local attackers to execute arbitrary shell commands through unsanitized user input passed to subprocess.run() with shell=True. Affects versions prior to 1.5.128. Two attack vectors exist: direct exploitation via hook configuration (pre_run_command/post_run_command) and automated exploitation through .praisonai/hooks.json lifecycle hooks (BEFORE_TOOL/AFTER_TOOL). Agent prompt injection enables persistent compromise by overwriting hooks.json, executing payloads silently at every lifecycle event without user interaction. No public exploit identified at time of analysis.
Any authenticated workspace member on PraisonAI Platform 0.1.8 and earlier can delete dependency edges attached to owner-created issues by routing the request through a member-owned related issue, because the DELETE dependency endpoint checks delete permission only against the caller-selected issue ID. Exploitation requires a valid member account (CVSS PR:L), a shared workspace, and a pre-existing dependency edge linking a member-owned issue to an owner-created issue; impact is limited to unauthorized removal of dependency relationships, with no data exposure or service disruption. No public exploit code was identified at time of analysis, and this is a moderate missing-authorization flaw rather than a high-urgency priority.
An attribute-read sandbox bypass in the PraisonAI multi-agent framework (pip package praisonaiagents before 1.6.59) lets prompt-influenced Python code reach blocklisted dunder attributes such as __class__, __bases__, __globals__ and __dict__, exposing in-process objects and secrets to the attacker. Exploitation requires the execute_code tool's sandbox mode with approval automatically granted (for example via PRAISONAI_AUTO_APPROVE or the YAML auto-approval path), after which two CPython semantics are chained: runtime string assembly evades the AST blocklist and str.format/str.format_map resolve dotted fields through C-level attribute access that never consults the Python-level _safe_getattr wrapper. The result is a high-confidentiality read primitive rather than a complete in-process execution chain; the vendor has published a fixed release (1.6.59) plus a public GitHub advisory containing a reproducer, and there is no CISA KEV listing indicating active exploitation.
PraisonAI's Server-Sent Events (SSE) server accepts /publish, /events, and /info requests without ever checking the ServerConfig.auth_token value, so any client that can reach the listening port can broadcast arbitrary events into every connected client's stream and read back server configuration and connected-client counts. Affected are praisonaiagents releases prior to 1.6.58 (some package metadata lists 1.6.59 as the fixed version); the npm-style pip package is the delivery vehicle and the flaw only manifests when the optional SSE server mode is started. Public proof-of-concept curl commands are published in the GitHub advisory (GHSA-35w5-pcw4-jx94), but there is no CISA KEV listing and no confirmed active exploitation; CVSS 4.3 with an adjacent-network vector reflects a real but bounded integrity/confidentiality problem rather than remote code execution.
Server-Side Request Forgery in PraisonAI before version 4.6.58 allows unauthenticated remote attackers to force the application server to make HTTP requests to internal network resources, including cloud metadata endpoints (169.254.169.254), loopback services, and RFC 1918 hosts. Two independent bypass paths exist in the Jobs API webhook_url validator: a DNS rebinding path exploiting the TOCTOU gap between validation and request dispatch, and a fail-open condition where socket.gaierror exceptions are silently swallowed, accepting unresolvable domains with no validation at all. A detailed proof-of-concept including curl commands is published in the GHSA advisory; no CISA KEV listing was present at time of analysis.
Unauthorized filesystem mutation in praisonaiagents allows an LLM-controlled agent to rewrite arbitrary on-disk source files by invoking ast_grep_rewrite with dry_run=False, bypassing the @require_approval authorization gate uniformly enforced on every sibling mutation tool in the framework. All praisonaiagents releases prior to 1.6.58 are affected; the vulnerable function is registered as a top-level tool and exposed through the code_intelligence built-in profile. Exploitability is confirmed by a proof-of-concept in GHSA advisory GHSA-cfxv-8fw8-rwpv, and a secondary defect causes the function to return 'No changes made' to the caller even when files were modified, silently concealing the write.
Memory exhaustion in PraisonAI's MCP HTTP Stream server allows remote unauthenticated attackers to crash the service by flooding the initialize endpoint with requests. Each initialize call unconditionally appends a new dictionary to self._sessions with no eviction: the cleanup routine _cleanup_sessions is defined but has zero call sites in versions prior to 4.6.58, and the configured TTL is stored but never enforced. No public exploit is identified at time of analysis, but the attack requires only standard HTTP tooling against default deployments where no API key is configured.
PraisonAI's MCP HTTP-stream transport silently skips authentication when no API key is configured at startup, allowing unauthenticated clients to initialize sessions, enumerate tools via tools/list, and invoke arbitrary tools via tools/call. Affected versions are all releases before 4.6.78. Compounding this, the dispatcher passes tool-call arguments directly to handlers without validating them against the advertised inputSchema, meaning a client can supply malformed or out-of-schema arguments to any registered tool. No public exploit code or CISA KEV listing has been identified at the time of analysis.
PraisonAI's tool approval caching mechanism in versions before 1.6.78 allows an attacker who influences an AI agent's behavior within a session to bypass human-in-the-loop oversight by reusing a single user-granted approval across tool calls with entirely different, unreviewed arguments. The flaw (CWE-863: Incorrect Authorization) directly undermines the security boundary that tool approval is designed to enforce, enabling arbitrary file write operations after approval of a benign operation. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA's KEV catalog; however, the CVSS 4.0 score of 6.9 with high integrity impact reflects meaningful risk for any deployment relying on tool approval as a control.
Webhook signature verification is absent in PraisonAI AgentMail before version 4.6.78, permitting any unauthenticated network attacker to POST crafted message.received events directly to the webhook endpoint with spoofed sender identities. This bypasses configured sender allow/block lists, injecting arbitrary content into the AI agent's processing pipeline and causing the agent to dispatch replies to attacker-controlled addresses. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog, though the low-complexity, unauthenticated attack vector makes exploitation straightforward for any attacker with network access to the webhook endpoint.
Path traversal in PraisonAI before 4.6.78 enables file exfiltration outside the workspace by embedding traversal sequences (e.g., @../outside_secret.txt) or absolute paths in custom project command templates, which are then injected verbatim into model prompts. Users who process attacker-controlled command files expose all process-readable files - including credentials, environment variables, and application secrets - to whoever controls the model interaction. No public exploit code has been identified and PraisonAI is not listed in the CISA KEV catalog at time of analysis; a vendor patch is available.
Path traversal in PraisonAI's FastContext feature (praisonaiagents before 1.6.78) enables low-privileged network attackers to read arbitrary files outside the intended workspace sandbox. FastContextAgent.execute_tool() applies the workspace_path prefix only to relative paths, neither rejecting absolute path arguments nor canonicalizing joined paths before enforcing containment - meaning file-operation tools (grep_search, glob_search, read_file, list_directory) can be exploited with '../' sequences or direct absolute paths to exfiltrate host files. No public exploit has been identified at time of analysis, but the vulnerability is straightforward to trigger given the mechanics, and CVSS 4.0 rates the confidentiality impact on the vulnerable system as High.
Path traversal in PraisonAI's ContextGatherer component (all versions before 4.6.78) allows an attacker who can supply or manipulate .praisoncontext or .praisoninclude files to read arbitrary files outside the intended workspace directory, including sensitive system files accessible to the user running PraisonAI. The vulnerability stems from a complete absence of path validation before file inclusion, permitting both absolute paths and relative traversal sequences. No active exploitation has been confirmed (not listed in CISA KEV), and no public exploit code has been identified at time of analysis; however, the attack is conceptually simple and requires no special tooling once an attacker can influence project workspace files.
Unauthenticated blind SSRF via DNS rebinding in PraisonAI before 4.6.78 allows remote attackers to reach internal services through the Jobs API /api/v1/runs endpoint without credentials. The webhook_url parameter is validated at request intake but re-resolved at connection time, creating a TOCTOU window exploitable by an attacker who controls a malicious DNS server - flipping the resolved IP from a legitimate external address to an internal target after validation passes. No public exploit code or CISA KEV listing exists at time of analysis; the unauthenticated network vector (AV:N/PR:N) makes this a meaningful risk for any internet-exposed PraisonAI deployment, particularly in cloud environments where internal metadata APIs may be reachable.
Path traversal in PraisonAI (pip package praisonaiagents) before version 1.6.78 allows an untrusted checked-out repository to overwrite arbitrary files on a developer's machine by embedding a malicious `.praisonai/config.toml` that sets `defaults.output.output_file` to an absolute or directory-traversal path. When the developer subsequently constructs an Agent and calls `agent.start()` without an explicit output parameter, PraisonAI resolves the attacker-supplied path - creating parent directories as needed - and writes agent output there with the privileges of the running user. No public exploit code or CISA KEV listing has been identified; a vendor patch at version 1.6.78 and an upstream fix commit are available per GitHub Security Advisory GHSA-qjw5-xwrp-xwpq.
PraisonAI versions 4.6.10 through 4.6.58 allow shell command injection through its compute-bridged file tools: when a LocalManagedAgent or SandboxedAgent is instantiated with a compute provider attached, the bridge rewrites read_file, list_files and write_file into shell command strings built from raw path arguments, so a crafted path can break out of the quoting and run arbitrary commands on the host (compute="local") or inside the container (Docker). Rated CVSS 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), exploitation needs an authenticated low-privileged actor who can influence a file-tool path argument - for example via prompt injection, a chat endpoint or an automation webhook - and importantly does not require the operator to have granted the critical-marked execute_command tool, so least-privilege tool configurations do not prevent it. The vendor advisory ships a local proof-of-concept reproducer that confirms shell execution through a crafted path; no evidence of active exploitation is provided in the available data, and deployments without an attached compute provider or without the bridged file tools enabled are not affected.
The A2U agent event-stream server shipped with PraisonAI exposes unauthenticated endpoints for any operator who starts the documented `praisonai serve a2u` CLI entrypoint without first setting the A2U_AUTH_TOKEN environment variable, and this gap persists across versions 4.5.115 through 4.6.60 despite the earlier GHSA-f292-66h9-fpmf advisory claiming the unauthenticated-stream issue was fixed in 4.5.115. Remote unauthenticated attackers (CVSS PR:N) who can reach the service - which requires binding to an external interface such as `--host 0.0.0.0`, since the default loopback bind limits exposure to the local host - can subscribe to live agent event streams and read stream metadata, agent responses, tool calls and thinking/progress events, for a confidentiality-only impact rated 7.5. A public local-only PoV script and reproduction output exist in the advisory; that PoV is a harness shim rather than verified working exploit code against a live deployment, and there is no CISA KEV listing or other confirmation of active exploitation. The decisive mitigating control is that pre-setting A2U_AUTH_TOKEN before startup enables the route-level token check and returns 401, making this a config-dependent, default-off authentication gap rather than an unconditionally reachable flaw.
PraisonAI's kernel-enforced SandlockSandbox silently degrades to ordinary subprocess execution when the optional sandlock module imports but reports that Linux Landlock is unavailable, so code that was supposed to be confined can read files outside the configured allowed paths and open network connections even when the native policy was created with network=False. The affected path is code executed through SandboxConfig.native() with SandlockSandbox in the pip package praisonai from 4.5.110 up to (but not including) 4.6.61; the read_file/write_file/list_files helpers still apply safe_sandbox_path checks and are not the exposed surface. CVSS 3.1 scores this 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) because the sandbox escape crosses a security scope with high confidentiality and integrity impact, while the attacker is positioned as a local, low-privileged party able to supply code to the sandbox rather than an unauthenticated network attacker. A public proof-of-concept script ships with the advisory (demonstrated against v4.6.58) that shows both boundary crossings; no confirmed active exploitation (CISA KEV) or public working exploit code is indicated, and the vendor released 4.6.61 as the fix.
PraisonAI recipe execution in versions 4.5.87 through 4.6.60 allows an untrusted steps-based recipe to self-approve the default-denied execute_command shell tool, so an operator who never set allow_dangerous_tools=True can still end up running arbitrary OS commands with the PraisonAI process's privileges. The recipe-level gate (CWE-78/CWE-863) inspects only TEMPLATE.yaml requires.tools, while workflow.yaml agents.*.tools declarations and a top-level approve: list are parsed by YAMLWorkflowParser and installed into the approval registry as already approved. Exploitation is local and user-interaction driven (CVSS 7.8, AV:L/UI:R, PR:N), a public proof-of-value reference exists in the advisory demonstrating the bypass with a harmless printf canary rather than verified working exploit code, and no active exploitation (CISA KEV) is reported for this this_week-priority issue.
Any account holding the lowest 'member' role in a PraisonAI Platform workspace can permanently delete projects, agents, issues, labels, issue dependencies and issue-label attachments created by the workspace owner or by other members, because all six content DELETE endpoints verify workspace membership but never verify resource ownership or an owner/admin role. The flaw affects praisonai-platform from 0.1.4 up to the fix and scores CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/C:N/I:H/A:H), since an authenticated low-privileged user can destroy integrity and availability of workspace content while confidentiality is untouched. Exploitation requires a valid member account inside the targeted workspace - either invited by the victim or obtained through a compromised member credential - so the practical exposure is an insider or account-takeover scenario rather than a mass internet threat; there is no CISA KEV entry, no EPSS signal supplied and no confirmed working exploit package, though the vendor advisory publishes a full step-by-step reproduction.
Unauthenticated remote clients can enumerate the agents deployed on PraisonAI's AgentOS FastAPI surface and invoke them directly, because GET /api/agents and POST /api/chat are registered with no authentication and AgentOSConfig defaults the bind host to 0.0.0.0. This is an incomplete-fix exposure: the previously published patch for GHSA-pm96-6xpr-978x / CVE-2026-40151 (4.5.128) still accepts both no-credential and wrong-bearer requests, as do releases through 4.6.57 and current main, with the advisory's reproducer showing the chat route executing agent.chat() as an observable side effect. PraisonAI 4.6.59 is the version that closes the gap, and the issue is rated act_now because the default configuration puts an agent-control endpoint in reach of any network client, with consequences scaling to whatever tools, memory, private context, API integrations or paid model calls the deployed agents have. A public PoC reference exists in the advisory but is not verified as working exploit code, and no confirmed active exploitation is indicated in the available intelligence.
Server-side request forgery in the PraisonAI Async Jobs API lets an attacker who can submit jobs with a chosen webhook_url steer the server's completion callback into loopback, private-network, or cloud-metadata endpoints, bypassing the webhook guard that current releases do ship. The check is a time-of-check/time-of-use gap: the URL is validated with urlparse() and socket.gethostbyname() at request parsing and again when the Job object is built, but _send_webhook() hands the original hostname to httpx.AsyncClient.post() with no send-time revalidation or IP pinning, so a low-TTL attacker-controlled name can resolve public during validation and internal during delivery. Affected releases are pip packages praisonai from 4.5.126 through 4.6.58; the advisory publishes a local-only PoC that confirms the bypass in-process, but it is not verified as working exploit code against a live deployment, and there is no KEV or active-exploitation signal - consistent with the this_week priority label and an assessed AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N vector where blind SSRF impact depends heavily on what internal services the host can reach and whether they accept POST.
Path traversal in PraisonAI 2.6.0 through 4.6.57 lets an attacker-supplied GitHub template URI write outside the template cache and, once a normal cache entry exists for the same owner/repo/template prefix, delete an attacker-chosen directory via shutil.rmtree. The resolver keeps the user-controlled template path and ref verbatim and the cache layer joins them into ~/.praison/cache/templates/github/<owner>/<repo>/<template>/<ref> without normalization or a boundary check, so a ref such as @../../../../../../outside-target escapes the cache root; nothing triggers unless a user or automated service is induced to load the crafted github: URI (CVSS 3.1 8.1 High, AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H), which is why PraisonAI rates the flaw this_week rather than an emergency. A public PoC reference exists in the GitHub advisory in the form of a local-only reproducer that disables networking; it is not verified as working exploit code, there is no CISA KEV listing, and no EPSS data was supplied. The project patched the issue in 4.6.59.
Unauthenticated remote agent invocation in PraisonAI LinearBot 4.6.56 through 4.6.58: because LINEAR_WEBHOOK_SECRET is treated as optional and defaults to an empty string, the aiohttp webhook listener bound to 0.0.0.0 skips Linear-Signature HMAC verification entirely, so any network caller who can reach the endpoint can POST a forged 'Linear-Event: AgentSession' request that is parsed, backgrounded, and dispatched into BotSessionManager.chat(), causing the bot to run the configured agent and post comments back to Linear under the bot token. Exploitation requires the operator to have started LinearBot with a Linear token but without a webhook secret, and the listener to be reachable; deployments that do set the secret reject missing and invalid signatures with 401 before dispatch. A public proof-of-vulnerability harness exists that exercises the handler offline and monkey-patches the outbound comment path; it is not verified as working exploit code against deployed instances, and there is no confirmed active exploitation (no KEV entry).
Path traversal in PraisonAI's Dynamic Context module lets a caller of the exported agent tools (history_search/history_tail/history_get and terminal_tail/terminal_grep/terminal_commands) supply a run_id that is an absolute path, or an agent_id containing '../', so that the underlying HistoryStore and TerminalLogger build file paths that resolve outside the configured base directory. Versions 3.8.1 through 4.6.58 are affected; the flaw is confidentiality-only and constrained, since readable targets must carry the tool-imposed suffix (.jsonl for history tools, .log for terminal tools) and be readable by the PraisonAI process. The vendor has released 4.6.59, no CISA KEV entry or confirmed active exploitation is reported, and the advisory ships only a local proof-of-value harness that exercises the traversal against an installed package - a public PoC reference exists; it is not verified as remote working exploit code.
Unauthenticated remote agent enumeration and invocation in PraisonAI's AgentTeam.launch() / Agents.launch() HTTP server lets any client that can reach the listening port list deployed agents and trigger agent.chat() calls, burning model resources, reaching connected private context, and firing agent tools and workflow side effects. The affected artifact is the Python package praisonaiagents before 1.6.59, whose FastAPI server binds to 0.0.0.0 by default and accepts requests with no Authorization header - or even with an obviously wrong bearer token. Vendor-released patch: praisonaiagents 1.6.59 (PraisonAI v4.6.59); no public exploit identified at time of analysis, and the practical limiting factor is deployment: the routes are only remotely reachable if launch() is actually started and network-exposed rather than bound to localhost or placed behind an authenticating proxy.
Server-side request forgery in the SearxNG-backed search tools shipped with the praisonaiagents Python package before 1.6.62 lets prompt-injected content hijack the agent's outbound HTTP requests and read the responses back into the model's context, enabling internal service and API disclosure plus internal host/port enumeration. The vulnerable sink is the LLM-exposed searxng_url tool parameter, which is forwarded to requests.get() without any validation of scheme, host, port, or resolved address; search_web and searxng_search are part of the default agent tool profile, so any agent that ingests attacker-controlled web pages, files, or upstream tool output is in scope. The CVSS vector is AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:L (8.8) - no authentication is needed (PR:N), but exploitation depends on the agent actually processing malicious content and the model complying with the injected tool call (UI:R); confidential impact is high while integrity and availability impact are low. No public exploit identified at time of analysis; in cloud deployments the same primitive can reach the instance metadata endpoint (169.254.169.254) and potentially expose IAM credentials, though that requires the instance metadata service to be reachable from the agent's network position.
Authentication bypass in praisonai-platform before 0.1.6 lets any remote unauthenticated attacker mint a valid HS256 JSON Web Token and impersonate arbitrary users against protected API routes. The flaw is a hardcoded fallback signing secret ('dev-secret-change-me') combined with a production guard that never fires when the operator leaves both PLATFORM_JWT_SECRET and PLATFORM_ENV unset - the common mis-deploy - so the platform silently starts signing tokens with a publicly known literal drawn straight from the source code. CVSS 3.1 scores this 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and EPSS is 0.51% (42nd percentile); there is no CISA KEV listing and no public exploit identified at time of analysis, though exploitation requires nothing more than a forged token and no authentication whatsoever.
Unauthenticated authentication bypass in praisonai-platform prior to 0.1.6 (and PraisonAI before 4.6.51) allows a remote attacker to forge HS256 session JWTs using the publicly known default signing key 'dev-secret-change-me' and be accepted as any identity the attacker names in the token's sub claim, including a workspace owner. The vulnerable state is the shipped default: the documented startup command sets neither PLATFORM_JWT_SECRET (so the hardcoded fallback is used) nor PLATFORM_ENV (which stays at 'dev', leaving the startup and token-issuance guards default-open). CVSS 3.1 scores this 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), consistent with an unauthenticated full-compromise primitive; EPSS is low at 0.53% (43rd percentile), no public exploit code was identified at time of analysis, and there is no CISA KEV listing, although the flaw is trivially exploitable against default deployments and the only practical constraint is that workspace-owner takeover requires knowing the target owner's user/sub identifier.
PraisonAI's TypeScript MCP server (npm package `praisonai`, versions 1.5.0 through 1.7.1) exposes an HTTP JSON-RPC transport that performs no authentication or authorization, so any network client that can reach the listening port can call tools/call, resources/read, or prompts/get and trigger registered handlers with the server process's credentials and privileges. The server's startHttp() binds the unspecified address (all interfaces) with no host restriction and ignores the Authorization header entirely; the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8) confirms this is unauthenticated and remotely reachable, though exploitation requires the operator to have enabled the HTTP transport and made the port network-reachable. Publicly available exploit code exists (a public gist), but there is no evidence of confirmed active exploitation, and the EPSS score is low at 0.64% (49th percentile); the vendor-released fix is version 1.7.2.
Arbitrary command execution in the npm TypeScript package praisonai (versions 1.5.1 through 1.7.1) allows an attacker who can influence the string passed to the exported shell() helper to break out of its read-only allowlist by prefixing an approved command and appending a second one with shell chaining syntax such as 'echo ok; <payload>'. Because utility-tools.ts validates only the first whitespace-delimited token and then hands the complete original string to Node's child_process.exec(), the injected command runs with the PraisonAI process privileges. The flaw is fixed in 1.7.2; the advisory includes a deterministic local proof-of-value, and there is no CISA KEV listing or EPSS data indicating active exploitation at time of analysis.
The npm package praisonai exposes a SandboxExecutor 'network-isolated' mode that is advertised to users as 'No network access (proxy blocked)' but only injects http_proxy/https_proxy=http://localhost:0 without creating any operating-system network boundary, so sandboxed commands that ignore proxy environment variables can still open sockets directly. Versions 1.2.3 through 1.7.1 of the npm package are affected; an initial fix shipped in 1.7.2. A local-only proof-of-concept is described in the vendor advisory (a plain Node HTTP client reaches a loopback server while a proxy
Let me synthesize. Key facts: - CVE-2026-57134, PraisonAI (npm package "praisonai", TypeScript MCP security helper). - MCPSecurity.evaluatePolicy() only validates credentials for api-key/bearer; basic/oauth accept any non-empty Authorization header, skipping validate() callback, returning authenticated: true. - Affected: npm praisonai >= 1.5.1, <= 1.7.1; fixed in 1.7.2. CPE cpe:2.3:a:mervinpraison:praisonai:*:*:*:*:*:*:*:* - CVSS 8.2 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. But logically, exploitation requires the deployment to use basic or oauth auth policy — that's a configuration prerequisite. Hmm. CVSS PR:N given. My assessed vector: I'd argue PR:N is defensible from the attacker's perspective (attacker sends an arbitrary Authorization header without valid credentials). But the configuration requirement: the target must use basic/oauth policy. AV:N is fine. AC:L? Arguably AC:H because it requires non-default config (basic/oauth policy configured). Let me think: the guidance says choose PR honestly — if exploitation requires control over configuration files, admin access, or authentication, use PR:H or PR:L. Here the attacker doesn't need config access; they need the target to have configured basic or oauth. That's a configuration precondition, not attacker privilege. I'd keep PR:N and use AC:H? Hmm. Many would keep AC:L. Actually the exploit is trivially automatable once the target uses basic/oauth. I'll go AC:L, PR:N, but note the pre-condition. Hmm, but the rubric's example: "Requires write access to the httpd configuration, so PR:H and AC:H". That's different. Here attacker just sends header. I'll use AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N — matching but I should express independent judgment. Maybe I could argue I:L and A:N as given. Let me consider C:H — access to MCP tools and resources protected by policies → confidentiality high, integrity low. That's reasonable. I'll go with AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N — but then it's a copy. The instruction says "NOT
Code escaping sandbox in the PraisonAI npm package's built-in codeMode tool (praisonai 1.4.0 through 1.7.1) lets anyone who can influence the code string read host files, write or modify files, spawn subprocesses, and consume host process resources, despite the tool advertising a sandbox boundary. The implementation blocks a handful of literal source patterns and shadows process and require with undefined properties, but untrusted code can walk the JavaScript prototype chain (for example ({}).constructor.constructor) to recover the real Function constructor and reach process.mainModule.require, bypassing both controls at low complexity. The vulnerability is rated 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) with the vector indicating some prior privilege or context is needed to reach the tool; EPSS is low (0.65%, 49th percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis, but the low attack complexity and high confidentiality, integrity, and availability impact make this a genuine high-priority fix rather than an inflated score.
Ar
Unauthenticated MCP tool invocation in PraisonAI (praisonaiagents 0.6.0–1.6.58 and praisonai 3.10.0–4.6.58) lets a malicious website use DNS rebinding to reach a local or internal ToolsMCPServer SSE endpoint on /sse and /messages/, enumerate registered tools, and invoke them with the server user's privileges. The legacy SSE wrapper performs no Host, Origin, or authentication enforcement, while the newer Streamable HTTP transport rejects the same hostile Origin with HTTP 403, isolating the flaw to the legacy SSE path. An initial remediation ships in praisonaiagents
PraisonAI deployments that opt out of authentication by setting PRAISONAI_CALL_AUTH=disabled expose the /api/v1/
PraisonAI's optional standalone async-jobs HTTP server can be driven by any unauthenticated network client that can reach its listener, which binds 0.0.0.0:8005 by default, because every route under /api/v1/runs lacks authentication and per-job ownership checks. An attacker can submit jobs carrying attacker-controlled prompts and agent YAML/configuration, causing the operator's process to execute agents with access to its environment variables, service credentials, and connected tool capabilities, and can also list, read, stream, cancel, or delete any job system-wide. Rated CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), with publicly available exploit code exists per SSVC exploitation: poc, an EPSS of 0.97% (60th percentile), and no CISA KEV listing; the vendor has published patched releases.
PraisonAI's WhatsApp and Linear bot webhook handlers fail open when their shared-secret environment variables are unset: HMAC signature verification is skipped entirely and the raw JSON body is parsed and dispatched as a trusted platform event. Any remote client that can reach the bot's webhook route (default /webhook) can forge WhatsApp messages or Linear AgentSession/Comment events without authentication, impersonating platform users and injecting attacker-controlled content into agent prompts and actions. The flaw affects releases before 4.6.59, is trivially automatable with a single unsigned HTTP POST, and no public exploit code or active exploitation has been identified at time of analysis.
Authentication bypass in PraisonAI's `recipe serve` command: when an operator selects `auth: api-key` or `auth: jwt` in a recipe YAML but omits the matching `api_key:`/`jwt_secret:` value and does not export PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET, APIKeyAuthMiddleware and JWTAuthMiddleware take a fail-open branch and forward every non-`/health` request unauthenticated to the recipe execution, input, and output surfaces, potentially triggering connected tools. Remote unauthenticated attackers who can reach an exposed recipe-serve endpoint (CVSS:3.1/AV:N/PR:N/UI:N) can therefore act as if authenticated, though independent analysis raises attack complexity to AC:H because the rawe 9.8 vendor score only manifests under a specific operator mis-deployment - the fail-open does not occur when the secret is set or when authentication was never enabled. Publicly available exploit code exists per the SSVC exploitation signal (poc), EPSS is 0.90% (58th percentile), and the issue is not listed in CISA KEV; it is fixed in 4.6.58.
Path traversal in PraisonAI before 4.6.59 allows prompt-influenced calls to code agent tools to read and modify arbitrary files outside any intended project boundary when an application exposes CODE_TOOLS, code_read_file, code_search_replace, or code_apply_diff before calling set_workspace(). The global _workspace_root defaults to None, and the lower-level file helpers silently skip path containment checks when workspace is falsy - a fail-open design identical to a previously patched write_file path (GHSA-hvhp-v2gc-268q). A proof-of-concept exists per SSVC data; no confirmed active exploitation in CISA KEV.
Unauthenticated path traversal in PraisonAI's Jobs API (versions prior to 4.6.59) allows any remote caller to read arbitrary files on the server. The `agent_file` field in `POST /api/v1/runs` accepts absolute or directory-traversing filesystem paths with no validation, allowlist, or authentication gate; the executor passes the value directly to `yaml.safe_load(open(agent_file))`. An attacker with network access to port 8005 can exfiltrate credentials, SSH private keys, environment variables, and any file readable by the service account. A working proof-of-concept is publicly available in the GitHub security advisory GHSA-p4pj-vh7h-6cqh.
Server-Side Request Forgery in PraisonAI's multi-agent web tooling allows an authenticated user to exfiltrate internal service responses by supplying a hostname whose DNS A record resolves to a loopback, RFC-1918, link-local, or cloud-metadata address. The SSRF guard in `SpiderTools._validate_url` → `_host_is_blocked` inspects only literal IP encodings and silently falls through for any DNS hostname, meaning a static internal A record is sufficient - no DNS rebinding race is required. Affected are praisonaiagents versions up to 1.6.48 (per GHSA) across the `scrape_page`, `crawl`, `extract_links`, `extract_text`, and `@url` mention-fetch surfaces; the fix ships in praisonaiagents 1.6.58/1.6.59 and PraisonAI 4.6.58. No public exploit identified at time of analysis, though SSVC notes a proof-of-concept exists.
IMAP command injection in the PraisonAI praisonaiagents email tools before 1.6.59 lets LLM-controlled arguments (from_addr, subject, query, message_id) break out of quoted IMAP SEARCH criteria and inject arbitrary IMAP commands, giving access to, modification of, or deletion of mailbox data. Exploitation requires an agent deployed with email credentials configured (EMAIL_ADDRESS and EMAIL_PASSWORD) and with the search_emails, reply_email, or archive_email tools exposed, plus an attacker able to steer the tool-call arguments — typically via crafted or indirect prompt injection reaching the agent. The advisory includes a static proof-of-concept data-flow trace, and CISA's SSVC assessment records exploitation status as 'poc'; the flaw is not listed in CISA KEV, and no EPSS score was supplied.
WebSocket origin-validation bypass in PraisonAI's Browser Server (praisonai/browser/server.py) before 4.6.58 lets an attacker forge a Chrome-extension Origin header and drive connected browser extensions. The check uses re.match() against the unanchored pattern chrome-extension://[a-z0-9]{32}, so any Origin with 32+ trailing characters is accepted before websocket.accept(), after which start_session commands trigger arbitrary browser automation, cookie theft, and screenshot capture. This is a patch bypass of CVE-2026-40289 (GHSA-8x8f-54wf-vv92); a working PoC is published in the advisory, though it is not in CISA KEV - no public exploit weaponization beyond the advisory PoC is identified.
Cross-site request forgery against the PraisonAI MCP HTTP-stream transport allows unauthenticated remote attackers to execute arbitrary MCP tools on a developer's local machine when a victim visits a malicious webpage. The attack is enabled by a flawed prefix-match origin check (`startswith`) in versions prior to 4.6.58 that accepts `http://localhost.attacker.com` as a valid localhost origin, and is further facilitated by the absence of a default API key and the CORS simple-request mechanism (Content-Type: text/plain) that bypasses browser preflight. The highest-impact consequence is persistent prompt injection: a forged request can write attacker-controlled agent instruction files that the runtime loads on every subsequent agent run. No public exploit is identified at time of analysis; vendor-released patch 4.6.58 is confirmed.
Authentication fail-open in PraisonAI's Recipe HTTP server allows unauthenticated remote attackers to invoke recipe execution endpoints despite authentication being nominally enabled. Versions prior to 4.6.58 of the pip package are affected: when the server is started with --auth api-key or --auth jwt but the corresponding PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET environment variable is absent, create_auth_middleware() silently bypasses all authentication checks. The CLI safety check that blocks external binding only verifies auth mode is not 'none', failing to detect this secret-absent misconfiguration, leaving POST /v1/recipes/run, /v1/recipes/stream, and /v1/recipes endpoints fully open to unauthenticated callers. No active exploitation is confirmed (not in CISA KEV); vendor-released patch is available in v4.6.58.
Path traversal in praisonaiagents prior to 1.6.58 allows a low-privileged caller to write arbitrary JSON files to any process-writable filesystem location by supplying a crafted user_id containing ../ sequences to the FileMemory constructor. All versions of the praisonaiagents pip package below 1.6.58 are affected; the vulnerability exists in the core library's FileMemory class, not an example or optional component. A detailed proof-of-concept is included in the GitHub Security Advisory (GHSA-gxmw-5f7x-6g22), and no public exploit identified at time of analysis beyond that PoC; no CISA KEV listing exists.
PraisonAI's `praisonai serve` subsystem (agents and unified modes) accepts an `--api-key` CLI flag that is parsed but never wired into the underlying FastAPI application, leaving POST /agents, POST /agents/{name}, and POST /api/v1/agents/{id}/invoke fully unauthenticated regardless of any key configured by the operator. All versions prior to 4.6.58 are affected, with the flaw present since approximately 4.6.34 when the serve subsystem first shipped. A public proof-of-concept exists per the GHSA advisory; no public exploit identified at time of analysis in CISA KEV, but the zero-authentication network attack surface makes this a high-priority fix for any deployment exposing the serve interface to untrusted networks.
Unauthenticated remote agent invocation in PraisonAI versions 4.6.34 through 4.6.57 allows any network-reachable caller to execute configured agents via POST /agents and POST /agents/{agent_name} despite an operator-supplied --api-key. The FastAPI app created by _create_agents_app() accepts the key at the CLI layer but never applies it as middleware or a route dependency, rendering the documented authentication control entirely inert on those endpoints. A proof-of-concept is included in GHSA-7ww9-85pg-cv4x, and the flaw is fixed in v4.6.58 via an _authorise_request() method that enforces Bearer or X-Auth-Token header validation.
SSRF protection bypass in PraisonAI's praisonaiagents library (all versions before 1.6.58) lets low-privileged users route agent web-fetching functions to internal HTTP services by supplying hostnames - such as 127.0.0.1.nip.io - that pass the static IP blocklist in spider_tools._host_is_blocked() because the function never performs DNS resolution before validation. The affected functions scrape_page, extract_links, crawl, and extract_text are registered as default LLM-callable agent tools, so any agent prompted to retrieve a user-supplied URL will trigger this path; a live proof-of-concept is documented in the GitHub Security Advisory (GHSA-x44h-65qv-cw74), confirming that publicly available exploit code exists. The CVSS scope change (S:C) and high confidentiality impact (C:H) reflect real ability to exfiltrate responses from internal services such as cloud metadata endpoints or localhost-bound APIs.
Authentication bypass in PraisonAI's AgentServer component exposes all routes - /publish, /events, /info, /health - to unauthenticated remote callers, even when operators have explicitly configured an auth_token in ServerConfig. The AgentServer._create_app factory never reads or enforces the configured token, rendering it dead code while /info actively misleads operators by displaying it as masked ('***'), creating a false sense of security. No public exploit code has been identified at time of analysis, and it is not listed in CISA KEV; the fix is confirmed in praisonaiagents 1.6.58.
Server-side request forgery in PraisonAI's web_crawl() function (versions 1.5.128-1.6.57) allows an attacker who can influence URLs processed by agent or tool workflows to exfiltrate responses from internal services, private network hosts, and cloud metadata endpoints such as AWS IAM credential URLs. This is a confirmed patch bypass of the previously disclosed SSRF class in CVE-2026-40160 and GHSA-8f4v-xfm9-3244, exploiting the fact that the httpx fallback client uses follow_redirects=True without revalidating redirect destinations against the original host blocklist. No public exploit code and no CISA KEV active exploitation designation have been identified at time of analysis.
Arbitrary Python code execution in PraisonAI's workflow include feature allows an attacker who controls a local recipe directory to execute arbitrary code as the PraisonAI process user. Affected are praisonai 3.9.26-4.6.57 and praisonaiagents 0.12.12-1.6.57. This is a hardening bypass: the vulnerable sink in Workflow._execute_include() skips the PRAISONAI_ALLOW_TEMPLATE_TOOLS/PRAISONAI_ALLOW_LOCAL_TOOLS opt-in gates and the centralized safe loader that protect all other tools.py autoload paths, making it a distinct variant within an established advisory family. No public exploit or CISA KEV listing has been identified at time of analysis.
Unauthenticated remote command execution in PraisonAI's bundled Claude GitHub Actions workflow (versions before 4.6.40) lets an outside contributor run arbitrary shell code on the CI runner by opening a fork pull request whose branch name contains shell metacharacters and posting an @claude comment. Two compounding flaws enable this: the workflow interpolates the attacker-controlled branch name directly into an unquoted Bash run: block, and it triggers for any @claude comment without verifying the commenter is a trusted collaborator. Because the job runs with a GitHub App token holding write permissions plus OIDC and gh/git access, injected commands can be chained via $GITHUB_PATH into later privileged steps to gain repository write, PR/issue manipulation, or OIDC-token abuse. No public exploit identified at time of analysis.
Arbitrary code execution in PraisonAI (praisonaiagents) before 1.6.78 lets an attacker who can drop a Python file into a plugin directory run their own code. The plugin manager auto-discovers and executes any .py file found in project-level or user-home .praisonai/plugins/ directories at initialization, with no code signing, integrity checks, or sandboxing. VulnCheck reported it under CWE-94; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Path-traversal remote code execution in PraisonAI (mervinpraison/praisonai) before 1.6.78 lets an authenticated agent user abuse SkillTools.run_skill_script(), which executes skill scripts without validating that the supplied path stays inside the intended working directory. Because absolute file paths are accepted, a low-privileged attacker can point the skill runner at any executable script on the host and run it. No public exploit code has been identified and it is not in CISA KEV, but the flaw was reported by VulnCheck and a GitHub Security Advisory (GHSA-c44f-37qr-gw3f) confirms the fix.
Broken authorization in PraisonAI Platform before 0.1.9 lets any authenticated workspace member modify shared label taxonomy and issue-label associations they should not control, renaming and recoloring shared labels and adding or removing labels on issues created by owners or admins. The flaw (CWE-862, missing authorization) stems from label PATCH and issue-label POST/DELETE endpoints trusting workspace membership without enforcing owner/admin role checks. Reported by VulnCheck with a vendor patch available; there is no public exploit identified at time of analysis and it is not in CISA KEV.
OS command execution in PraisonAI before 4.6.78 lets an attacker who can supply a workflow definition escape the inline-Python sandbox and run arbitrary shell commands with the privileges of the agent process. The flaw lives in JobWorkflowExecutor._exec_inline_python(), whose AST-based validation fails to reject `import os` followed by `os.system()`, turning a malicious YAML workflow file into RCE. No public exploit code or CISA KEV listing is identified at time of analysis, though the bypass technique is described in detail in the vendor advisory.
Webhook signature-verification bypass in PraisonAI before 4.6.78 lets unauthenticated attackers forge Svix 'message.received' events when the framework runs in AgentMail webhook mode. Because incoming payloads are trusted without validating the Svix signature (CWE-287), an attacker can POST crafted JSON to the webhook endpoint and cause configured agents to process attacker-chosen sender addresses and message bodies. A vendor patch exists (4.6.78); there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Authentication bypass in PraisonAI before 4.6.78 lets a remote, unauthenticated attacker reach the Call API agent-invocation endpoints when the deployment runs with PRAISONAI_CALL_AUTH=disabled. Because the localhost-only safeguard derives the bind host from the client-supplied HTTP Host header, an attacker on the network can send a spoofed 'Host: 127.0.0.1' header to defeat the restriction and both enumerate and invoke registered agents. Vendor patch is available (reported by VulnCheck); no public exploit identified at time of analysis and it is not listed in CISA KEV.
Code injection in PraisonAI before 4.6.78 lets attackers who control deployment configuration achieve arbitrary Python execution because the API-server deployment generator fails to safely encode the deploy.api.host and agents_file values before emitting them into generated Python source (CWE-94). Injected expressions run when the generated API server starts or handles requests, yielding full code execution in the server process. No public exploit is identified at time of analysis; the flaw was reported by VulnCheck and a vendor patch is available.
Server-side request forgery in PraisonAI's web_crawl tool (versions before 1.6.78) allows an authenticated attacker to reach internal HTTP services and exfiltrate their response bodies. The flaw stems from a time-of-check/time-of-use gap: hostnames are validated once but re-resolved at connection time without IP pinning, so DNS rebinding defeats the SSRF allowlist. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the technique is well-documented and the vendor has released a fix in 1.6.78.
Security-policy bypass in PraisonAI before 4.6.78 renders the default Subprocess Sandbox backend inert, so administrator-defined blocked_commands, blocked_paths, blocked_imports, allow_subprocess, and allow_file_write restrictions are silently ignored. Any actor able to feed instructions into a PraisonAI agent can execute arbitrary subprocess commands, read sensitive files, and perform destructive file operations even though an explicit deny policy is configured. Reported by VulnCheck with a CVSS 4.0 base score of 8.7; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Remote code execution in PraisonAI before 1.6.78 allows attackers to run arbitrary Python on the host by manipulating the LLM that drives the CodeAgent component. Because CodeAgent._execute_python() runs LLM-generated code with no AST validation, import restrictions, or sandbox, an attacker who can shape model output via prompt injection can exfiltrate all environment secrets and gain full control of the agent host. VulnCheck reports the flaw with a maximum CVSS 4.0 score of 10.0; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Root-level command execution and arbitrary file write in PraisonAI's AICoder component (all versions before 4.6.78) let an attacker with chat-interface access weaponize LLM tool calls: because file paths are not validated and shell commands are not sanitized, a crafted prompt can write files anywhere on the host and run arbitrary shell commands as root. Reported by VulnCheck and fixed in 4.6.78, this is a CVSS 9.4 (v4.0) flaw with no public exploit identified at time of analysis, though the injection path is trivial to trigger for any user who can reach the chat.
Broken authorization in PraisonAI Platform (praisonai-platform) before 0.1.9 lets any low-privileged workspace member modify owner- or admin-created projects, issues, and agents because the PATCH routes only check for workspace-member role instead of owner/admin. Because a member can reassign a project's lead_id to their own user id, they can then satisfy and bypass the delete route's owner/admin check to destroy owner-created projects. No public exploit identified at time of analysis, though the flaw is trivially reachable by any authenticated tenant member.
System prompt extraction and unauthorized tool invocation in PraisonAI before 4.6.78 arise because the prompt-injection defense ships with its blocking threshold defaulting to CRITICAL, so HIGH-severity injection attempts are detected and logged but never blocked. Any remote user interacting with a PraisonAI agent can submit single-vector prompt injection (instruction overrides, financial manipulation) that scores HIGH and passes through, leaking the system prompt and triggering agent tools without authorization. No public exploit identified at time of analysis, and the issue is not in CISA KEV; the vendor CVSS 4.0 score is 8.7 (High).
Server-side request forgery in PraisonAI's Crawl4AI/Chromium crawling backend (all versions before 1.6.78) lets low-privileged users bypass URL allowlist/SSRF validation through DNS rebinding and HTTP redirects, causing the headless browser to reach internal-only services and return their responses. Because validation happens before the browser dereferences the URL, an attacker-controlled host can pass the check and then resolve or redirect to internal endpoints, exposing sensitive internal data (demonstrated with canary values). Reported by VulnCheck; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Unauthenticated agent access in PraisonAI before 1.7.3 lets remote attackers read agent instructions and system prompts and directly invoke agents because the server ships with insecure defaults - binding to all network interfaces (0.0.0.0), enforcing no API key, and allowing wildcard CORS. Any attacker who can reach the service can call GET /api/agents to exfiltrate proprietary prompt logic or POST /api/chat to abuse the agents without credentials. There is no public exploit identified at time of analysis, but exploitation is trivial and requires no special tooling given the missing authentication.
SQL/CQL injection in PraisonAI's PGVector and Cassandra knowledge-store backends before 4.6.78 allows a caller who controls the create_collection() dimension argument to inject arbitrary database tokens. Although the code validates schema, keyspace, and collection-name identifiers, the dimension value - typed as int but never enforced at runtime - is string-interpolated directly into the vector column of the generated CREATE TABLE DDL, so a payload like '3); DROP TABLE tenant_secrets; --' executes against the backing database. No public exploit identified at time of analysis; the flaw was reported by VulnCheck and a vendor patch is available.
Remote code execution in PraisonAI before 4.6.78 lets an attacker who can supply the agents_file parameter to deploy/api.py run arbitrary Python, because that value is interpolated directly into an f-string that is later executed as generated server code via subprocess.Popen(). The CVSS 4.0 base score is 9.4 and the vector requires high privileges (PR:H), meaning the attacker must already be able to reach and drive the deployment API. No public exploit has been identified at time of analysis and it is not on the CISA KEV list.
Broken authorization in PraisonAI Platform before 0.1.9 lets an authenticated workspace member delete owner-created issue dependencies they should not be able to remove. The DELETE dependency route accepts either endpoint of a dependency edge and validates delete permission only against the caller-supplied issue URL, so a member blocked (403) via the owner's issue endpoint can delete the same edge by targeting their own member-owned issue endpoint. Reported by VulnCheck with a vendor patch available; no public exploit identified at time of analysis and it is not on CISA KEV.
Arbitrary Python code execution in PraisonAI (praisonaiagents) before 1.6.78 occurs when AgentFlow._resolve_pydantic_class resolves a string output_pydantic reference in a workflow step, causing the framework to import a sibling tools.py from the workflow file's directory via importlib exec_module without any sandboxing. Because this loader ignores the PRAISONAI_ALLOW_*_TOOLS environment guardrails, an attacker who supplies a malicious workflow file plus its tools.py runs code with the workflow runner's privileges the moment the workflow is executed via WorkflowManager or loaded through load_yaml. No public exploit is identified at time of analysis, and the flaw is not listed in CISA KEV.
Command execution allowlist bypass in PraisonAI before 4.6.78 lets a low-privileged attacker who can supply commands to the framework's restricted-execution feature slip past its shell-metacharacter filters by abusing find's built-in -exec, -execdir, and -delete actions. Because those actions run binaries and delete files entirely inside the find process, they never trip the metacharacter allowlist, so the attacker can read blocked files, delete arbitrary files, and launch non-allowlisted binaries. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the CVSS 4.0 base score of 8.7 (High) reflects full loss of confidentiality, integrity, and availability of the affected system.
GitHub Actions credential leakage in PraisonAI through ArtiPACKED attack exposes GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN in workflow artifacts. Versions 4.5.139 and below persist credentials in .git/config via actions/checkout without disabling persist-credentials, allowing any user with read access to public repository artifacts to extract tokens and compromise the supply chain. CVSS 9.1 (Critical) with network-accessible, unauthenticated attack vector. EPSS data not provided; no confirmed active exploitation (KEV status not indicated), but attack technique is publicly documented by Palo Alto Unit42 and widely reported. Vendor-released patch available in version 4.5.140.
Unauthenticated remote session hijacking in PraisonAI's browser bridge (versions <4.5.139) and praisonaiagents (<1.5.140) allows network attackers to control browser automation sessions without authentication. The /ws WebSocket endpoint accepts connections from any client omitting the Origin header, enabling attackers to send start_session commands that hijack idle browser-extension sessions and receive all automation outputs. With CVSS 9.1 (Critical) scoring driven by network attack vector, low complexity, and no authentication requirement (AV:N/AC:L/PR:N), this represents a severe risk in any deployment where the default 0.0.0.0 binding exposes the service to untrusted networks. No public exploit identified at time of analysis, though exploitation requires only basic WebSocket client capabilities.
Arbitrary command and code execution in PraisonAI's workflow engine (versions <4.5.139) and praisonaiagents (<1.5.140) allows remote unauthenticated attackers to execute shell commands and Python code through malicious YAML workflow files. The vulnerability stems from unsafe processing of 'run:', 'script:', and 'python:' directives in job-type workflows without validation or sandboxing. With a critical CVSS score of 9.8 and network-accessible attack vector requiring no privileges or user interac
Arbitrary Python code execution in PraisonAI ≤4.5.138 occurs when malicious tools.py files are automatically imported from the current working directory without validation. Attackers placing a crafted tools.py in shared projects, cloned repositories, or writable workspaces achieve immediate code execution with full process privileges upon PraisonAI startup. EPSS data not available, but the local attack vector (AV:L) requiring no privileges (PR:N) or user interaction (UI:N) enables exploitation through supply chain and workspace poisoning attacks. No public exploit identified at time of analysis, though the vulnerability is trivial to exploit given the straightforward code injection mechanism.
SQL identifier injection in PraisonAI's SQLiteConversationStore allows authenticated local attackers with configuration control to extract database schema and manipulate query results. The vulnerability affects PraisonAI versions prior to 4.5.133, where unsanitized table_prefix values are concatenated into SQL queries via f-strings. Attackers controlling configuration inputs (from_yaml/from_dict) can inject SQL fragments to access internal SQLite tables like sqlite_master and execute UNION-based injections. A vendor patch is available in version 4.5.133. No public exploit code or active exploitation confirmed at time of analysis. CVSS 7.2 indicates local attack vector with low complexity but requires low privileges and present attack complexity conditions.
Server-Side Request Forgery (SSRF) in PraisonAIAgents versions prior to 1.5.128 allows unauthenticated attackers to manipulate LLM agents into crawling arbitrary internal URLs. The httpx fallback crawler accepts user-supplied URLs without host validation and follows redirects, enabling access to cloud metadata endpoints (169.254.169.254), internal services, and localhost. Response content is returned to the agent and may be exposed in attacker-visible output. This vulnerability is the default behavior on fresh installations without Tavily API keys or Crawl4AI dependencies. No public exploit identified at time of analysis.
Arbitrary code execution in PraisonAI multi-agent system (<4.5.128) via Python sandbox escape. Incomplete AST attribute filtering allows type.__getattribute__ trampoline to bypass restrictions on __subclasses__, __globals__, and __bases__, enabling untrusted agent code to break containment. Attack requires local access and user interaction to execute malicious code. No public exploit identified at time of analysis.
Path traversal in PraisonAI multi-agent teams system (versions prior to 4.5.128) enables arbitrary file overwrite through malicious .praison archive bundles. The cmd_unpack function in recipe CLI performs unvalidated tar extraction, allowing attackers to embed ../ path sequences that escape the intended extraction directory. Unauthenticated attackers can distribute weaponized bundles that, when unpacked by victims via 'praisonai recipe unpack' command, overwrite critical system files with attacker-controlled content. No public exploit identified at time of analysis.
Arbitrary code execution occurs in PraisonAI (all versions prior to 4.5.128) when a malicious tools.py file exists in the working directory. The framework automatically imports and executes this file during startup without validation or user consent, enabling unauthenticated local attackers to execute arbitrary Python code by placing a weaponized tools.py in directories accessed by users or CI/CD pipelines. User interaction is required (running praisonai command). No public exploit identified at time of analysis.
Environment variable exfiltration in PraisonAIAgents versions prior to 1.5.128 allows unauthenticated remote attackers to steal secrets (database credentials, API keys, cloud access keys) through shell_tools.py execute_command function. The vulnerability leverages deceptive command approval where unexpanded $VAR references shown to human reviewers differ from executed commands containing expanded environment variable values. Requires user interaction. No public exploit identified at time of analysis.
Server-side request forgery in PraisonAIAgents multi-agent system allows authenticated attackers to force internal network reconnaissance and data exfiltration through unvalidated URL crawling. The web_crawl() function in versions prior to 1.5.128 accepts arbitrary URLs from AI agents without scheme allowlisting, hostname blocking, or private network checks, enabling access to cloud metadata endpoints (AWS/Azure/GCP), internal services, and local filesystems via file:// URIs. Exploitation requires low-privileged authenticated access with network reachability and no user interaction. No public exploit identified at time of analysis.
Unauthenticated modification of the tool approval allowlist in PraisonAI multi-agent system (versions prior to 4.5.128) enables attackers to bypass human-in-the-loop safety controls by injecting dangerous tool names (shell_exec, file_write) into the allowlist via the /api/approval/allow-list gateway endpoint. The ExecApprovalManager then auto-approves agent invocations of these tools, circumventing the approval mechanism's core security function. Attack requires local access; no public exploit identified at time of analysis. CVSS 7.9 reflects high integrity impact with scope change due to compromised safety boundaries in agent workflows.
Unauthenticated resource exhaustion in PraisonAI versions prior to 4.5.128 allows remote attackers to drain OpenAI API credits and exhaust server resources. The /media-stream WebSocket endpoint in the call module accepts connections without authentication or Twilio signature validation, enabling unlimited concurrent sessions to OpenAI's Realtime API using the server's credentials. No public exploit identified at time of analysis. Affects PraisonAI deployments exposing the call module's WebSocket interface.
Server-Side Request Forgery in PraisonAI versions prior to 4.5.128 allows unauthenticated remote attackers to force the server to send HTTP POST requests to arbitrary internal or external destinations via an unvalidated webhook_url parameter in the /api/v1/runs endpoint. Attackers can abuse this to access cloud metadata services (AWS/GCP/Azure instance metadata), internal APIs, and network-adjacent services, potentially exposing credentials, configuration data, or triggering unauthorized actions. No public exploit identified at time of analysis. CVSS 7.2 indicates changed scope with low confidentiality and integrity impact.
Environment variable injection in PraisonAI deploy.py (versions prior to 4.5.128) allows authenticated local attackers to inject arbitrary environment variables into Google Cloud Run services during deployment. The vulnerability stems from improper validation of comma-separated gcloud CLI arguments, enabling attackers to manipulate openai_model, openai_key, or openai_base parameters with embedded commas, causing gcloud to parse injected content as additional KEY=VALUE pairs. This grants high-level access to confidential service configuration and permits unauthorized modifications. No public exploit identified at time of analysis.
Command injection in PraisonAIAgents memory hooks executor allows authenticated local attackers to execute arbitrary shell commands through unsanitized user input passed to subprocess.run() with shell=True. Affects versions prior to 1.5.128. Two attack vectors exist: direct exploitation via hook configuration (pre_run_command/post_run_command) and automated exploitation through .praisonai/hooks.json lifecycle hooks (BEFORE_TOOL/AFTER_TOOL). Agent prompt injection enables persistent compromise by overwriting hooks.json, executing payloads silently at every lifecycle event without user interaction. No public exploit identified at time of analysis.
Any authenticated workspace member on PraisonAI Platform 0.1.8 and earlier can delete dependency edges attached to owner-created issues by routing the request through a member-owned related issue, because the DELETE dependency endpoint checks delete permission only against the caller-selected issue ID. Exploitation requires a valid member account (CVSS PR:L), a shared workspace, and a pre-existing dependency edge linking a member-owned issue to an owner-created issue; impact is limited to unauthorized removal of dependency relationships, with no data exposure or service disruption. No public exploit code was identified at time of analysis, and this is a moderate missing-authorization flaw rather than a high-urgency priority.
An attribute-read sandbox bypass in the PraisonAI multi-agent framework (pip package praisonaiagents before 1.6.59) lets prompt-influenced Python code reach blocklisted dunder attributes such as __class__, __bases__, __globals__ and __dict__, exposing in-process objects and secrets to the attacker. Exploitation requires the execute_code tool's sandbox mode with approval automatically granted (for example via PRAISONAI_AUTO_APPROVE or the YAML auto-approval path), after which two CPython semantics are chained: runtime string assembly evades the AST blocklist and str.format/str.format_map resolve dotted fields through C-level attribute access that never consults the Python-level _safe_getattr wrapper. The result is a high-confidentiality read primitive rather than a complete in-process execution chain; the vendor has published a fixed release (1.6.59) plus a public GitHub advisory containing a reproducer, and there is no CISA KEV listing indicating active exploitation.
PraisonAI's Server-Sent Events (SSE) server accepts /publish, /events, and /info requests without ever checking the ServerConfig.auth_token value, so any client that can reach the listening port can broadcast arbitrary events into every connected client's stream and read back server configuration and connected-client counts. Affected are praisonaiagents releases prior to 1.6.58 (some package metadata lists 1.6.59 as the fixed version); the npm-style pip package is the delivery vehicle and the flaw only manifests when the optional SSE server mode is started. Public proof-of-concept curl commands are published in the GitHub advisory (GHSA-35w5-pcw4-jx94), but there is no CISA KEV listing and no confirmed active exploitation; CVSS 4.3 with an adjacent-network vector reflects a real but bounded integrity/confidentiality problem rather than remote code execution.
Server-Side Request Forgery in PraisonAI before version 4.6.58 allows unauthenticated remote attackers to force the application server to make HTTP requests to internal network resources, including cloud metadata endpoints (169.254.169.254), loopback services, and RFC 1918 hosts. Two independent bypass paths exist in the Jobs API webhook_url validator: a DNS rebinding path exploiting the TOCTOU gap between validation and request dispatch, and a fail-open condition where socket.gaierror exceptions are silently swallowed, accepting unresolvable domains with no validation at all. A detailed proof-of-concept including curl commands is published in the GHSA advisory; no CISA KEV listing was present at time of analysis.
Unauthorized filesystem mutation in praisonaiagents allows an LLM-controlled agent to rewrite arbitrary on-disk source files by invoking ast_grep_rewrite with dry_run=False, bypassing the @require_approval authorization gate uniformly enforced on every sibling mutation tool in the framework. All praisonaiagents releases prior to 1.6.58 are affected; the vulnerable function is registered as a top-level tool and exposed through the code_intelligence built-in profile. Exploitability is confirmed by a proof-of-concept in GHSA advisory GHSA-cfxv-8fw8-rwpv, and a secondary defect causes the function to return 'No changes made' to the caller even when files were modified, silently concealing the write.
Memory exhaustion in PraisonAI's MCP HTTP Stream server allows remote unauthenticated attackers to crash the service by flooding the initialize endpoint with requests. Each initialize call unconditionally appends a new dictionary to self._sessions with no eviction: the cleanup routine _cleanup_sessions is defined but has zero call sites in versions prior to 4.6.58, and the configured TTL is stored but never enforced. No public exploit is identified at time of analysis, but the attack requires only standard HTTP tooling against default deployments where no API key is configured.
PraisonAI's MCP HTTP-stream transport silently skips authentication when no API key is configured at startup, allowing unauthenticated clients to initialize sessions, enumerate tools via tools/list, and invoke arbitrary tools via tools/call. Affected versions are all releases before 4.6.78. Compounding this, the dispatcher passes tool-call arguments directly to handlers without validating them against the advertised inputSchema, meaning a client can supply malformed or out-of-schema arguments to any registered tool. No public exploit code or CISA KEV listing has been identified at the time of analysis.
PraisonAI's tool approval caching mechanism in versions before 1.6.78 allows an attacker who influences an AI agent's behavior within a session to bypass human-in-the-loop oversight by reusing a single user-granted approval across tool calls with entirely different, unreviewed arguments. The flaw (CWE-863: Incorrect Authorization) directly undermines the security boundary that tool approval is designed to enforce, enabling arbitrary file write operations after approval of a benign operation. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA's KEV catalog; however, the CVSS 4.0 score of 6.9 with high integrity impact reflects meaningful risk for any deployment relying on tool approval as a control.
Webhook signature verification is absent in PraisonAI AgentMail before version 4.6.78, permitting any unauthenticated network attacker to POST crafted message.received events directly to the webhook endpoint with spoofed sender identities. This bypasses configured sender allow/block lists, injecting arbitrary content into the AI agent's processing pipeline and causing the agent to dispatch replies to attacker-controlled addresses. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog, though the low-complexity, unauthenticated attack vector makes exploitation straightforward for any attacker with network access to the webhook endpoint.
Path traversal in PraisonAI before 4.6.78 enables file exfiltration outside the workspace by embedding traversal sequences (e.g., @../outside_secret.txt) or absolute paths in custom project command templates, which are then injected verbatim into model prompts. Users who process attacker-controlled command files expose all process-readable files - including credentials, environment variables, and application secrets - to whoever controls the model interaction. No public exploit code has been identified and PraisonAI is not listed in the CISA KEV catalog at time of analysis; a vendor patch is available.
Path traversal in PraisonAI's FastContext feature (praisonaiagents before 1.6.78) enables low-privileged network attackers to read arbitrary files outside the intended workspace sandbox. FastContextAgent.execute_tool() applies the workspace_path prefix only to relative paths, neither rejecting absolute path arguments nor canonicalizing joined paths before enforcing containment - meaning file-operation tools (grep_search, glob_search, read_file, list_directory) can be exploited with '../' sequences or direct absolute paths to exfiltrate host files. No public exploit has been identified at time of analysis, but the vulnerability is straightforward to trigger given the mechanics, and CVSS 4.0 rates the confidentiality impact on the vulnerable system as High.
Path traversal in PraisonAI's ContextGatherer component (all versions before 4.6.78) allows an attacker who can supply or manipulate .praisoncontext or .praisoninclude files to read arbitrary files outside the intended workspace directory, including sensitive system files accessible to the user running PraisonAI. The vulnerability stems from a complete absence of path validation before file inclusion, permitting both absolute paths and relative traversal sequences. No active exploitation has been confirmed (not listed in CISA KEV), and no public exploit code has been identified at time of analysis; however, the attack is conceptually simple and requires no special tooling once an attacker can influence project workspace files.
Unauthenticated blind SSRF via DNS rebinding in PraisonAI before 4.6.78 allows remote attackers to reach internal services through the Jobs API /api/v1/runs endpoint without credentials. The webhook_url parameter is validated at request intake but re-resolved at connection time, creating a TOCTOU window exploitable by an attacker who controls a malicious DNS server - flipping the resolved IP from a legitimate external address to an internal target after validation passes. No public exploit code or CISA KEV listing exists at time of analysis; the unauthenticated network vector (AV:N/PR:N) makes this a meaningful risk for any internet-exposed PraisonAI deployment, particularly in cloud environments where internal metadata APIs may be reachable.
Path traversal in PraisonAI (pip package praisonaiagents) before version 1.6.78 allows an untrusted checked-out repository to overwrite arbitrary files on a developer's machine by embedding a malicious `.praisonai/config.toml` that sets `defaults.output.output_file` to an absolute or directory-traversal path. When the developer subsequently constructs an Agent and calls `agent.start()` without an explicit output parameter, PraisonAI resolves the attacker-supplied path - creating parent directories as needed - and writes agent output there with the privileges of the running user. No public exploit code or CISA KEV listing has been identified; a vendor patch at version 1.6.78 and an upstream fix commit are available per GitHub Security Advisory GHSA-qjw5-xwrp-xwpq.