Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
105 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The /api/v1/runs endpoint accepts an arbitrary webhookurl in the request body with no URL validation. When a submitted job completes (success or failure), the server makes an HTTP POST request to this URL using httpx.AsyncClient. An unauthenticated attacker can use this to make the server send POST requests to arbitrary internal or external destinations, enabling SSRF against cloud metadata services, internal APIs, and other network-adjacent services. Details The vulnerability exists across the full request lifecycle: 1. User input accepted without validation — models.py:32: The field is a plain str with no URL validation — no scheme restriction, no host filtering. 2. Stored directly on the Job object — router.py:80-86: 3. Used in an outbound HTTP request — executor.py:385-415: 4. Triggered on both success and failure paths — executor.py:180-205: 5. No authentication on the Jobs API server — server.py:82-101: The createapp() function creates a FastAPI app with CORS allowing…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI’s MCP (Model Context Protocol) integration allows spawning background servers via stdio using user-supplied command strings (e.g., MCP("npx -y @smithery/cli ...")). These commands are executed through Python’s subprocess module. By default, the implementation forwards the entire parent process environment to the spawned subprocess: As a result, any MCP command executed in this manner inherits all environment variables from the host process, including sensitive data such as API keys, authentication tokens, and database credentials. This behavior introduces a security risk when untrusted or third-party commands are used. In common scenarios where MCP tools are invoked via package runners such as npx -y, arbitrary code from external or potentially compromised packages may execute with access to these inherited environment variables. This creates a risk of unintended credential exposure and enables potential supply chain attacks through silent exfiltration of secrets.…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
| Field | Value | |---|---| | Severity | Critical | | Type | Path traversal -- arbitrary file write via tar.extract() without member validation | | Affected | src/praisonai/praisonai/cli/features/recipe.py:1170-1172 | Summary cmdunpack in the recipe CLI extracts .praison tar archives using raw tar.extract() without validating archive member paths. A .praison bundle containing ../../ entries will write files outside the intended output directory. An attacker who distributes a malicious bundle can overwrite arbitrary files on the victim's filesystem when they run praisonai recipe unpack. Details The vulnerable code is in cli/features/recipe.py:1170-1172: The only check is whether the member is manifest.json. The code never validates member names -- absolute paths, .. components, and symlinks all pass through. Python's tarfile.extract() resolves these relative to the destination, so a member named ../../.bashrc lands two directories above recipedir. The codebase does contain a safe…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI automatically loads a file named tools.py from the current working directory to discover and register custom agent tools. This loading process uses importlib.util.specfromfilelocation and immediately executes module-level code via spec.loader.execmodule() without explicit user consent, validation, or sandboxing. The tools.py file is loaded implicitly, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named tools.py in the working directory is sufficient to trigger code execution. This behavior violates the expected security boundary between user-controlled project files (e.g., YAML configurations) and executable code, as untrusted content in the working directory is treated as trusted and executed automatically. If an attacker can place a malicious tools.py file into a directory where a user or automated system (e.g., CI/CD pipeline) runs praisonai, arbitrary code execution occurs immediately upon…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The safeextractall() function in PraisonAI's recipe registry validates archive members against path traversal attacks but performs no checks on individual member sizes, cumulative extracted size, or member count before calling tar.extractall(). An attacker can publish a malicious recipe bundle containing highly compressible data (e.g., 10GB of zeros compressing to ~10MB) that exhausts the victim's disk when pulled via LocalRegistry.pull() or HttpRegistry.pull(). Details The vulnerable function is safeextractall() at src/praisonai/praisonai/recipe/registry.py:131-162: The function iterates all tar members and checks for path traversal (absolute paths, .. components, resolved path escaping), but never inspects member.size. The TarInfo.size attribute is available on every member and represents the uncompressed size, but it is never read. This function is called from two locations: - LocalRegistry.pull() at line 396-397 - HttpRegistry.pull() at line 791-792 The publish() method…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI treats remotely fetched template files as trusted executable code without integrity verification, origin validation, or user confirmation, enabling supply chain attacks through malicious templates. --- Description When a user installs a template from a remote source (e.g., GitHub), PraisonAI downloads Python files (including tools.py) to a local cache without: 1. Code signing verification 2. Integrity checksum validation 3. Dangerous code pattern scanning 4. User confirmation before execution When the template is subsequently used, the cached tools.py is automatically loaded and executed via execmodule(), granting the template's code full access to the user's environment, filesystem, and network. --- Affected Code Template download (no verification): Automatic execution (no confirmation): --- Trust Boundary Violation PraisonAI breaks the expected security boundary between: - Data: Template metadata, YAML configuration (should be safe to load) - Code: Python files from…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Chainlit UI modules (chat.py and code.py) hardcode config.approvalmode = "auto" after loading administrator configuration from the PRAISONAPPROVALMODE environment variable, silently overriding any "manual" or "scoped" approval setting. This defeats the human-in-the-loop approval gate for all ACP tool executions, including shell command execution via subprocess.run(..., shell=True). An authenticated user can instruct the LLM agent to execute arbitrary single-command shell operations on the server without any approval prompt. Details The application has a well-designed approval framework supporting auto, manual, and scoped modes, configured via the PRAISONAPPROVALMODE environment variable and loaded by ToolConfig.fromenv() at interactivetools.py:81-106. However, both UI modules unconditionally override this after loading: chat.py:156-159: code.py:155-158: This flows to agenttools.py:347-348 in the acpexecutecommand function: The plan is auto-approved without user…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI's AST-based Python sandbox can be bypassed using type.getattribute trampoline, allowing arbitrary code execution when running untrusted agent code. Description The executecodedirect function in praisonaiagents/tools/pythontools.py uses AST filtering to block dangerous Python attributes like subclasses, globals, and bases. However, the filter only checks ast.Attribute nodes, allowing bypass via: The sandbox relies on AST-based filtering of attribute access but fails to account for dynamic attribute resolution via built-in methods such as type.getattribute, resulting in incomplete enforcement of security restrictions. The string 'subclasses' is an ast.Constant, not an ast.Attribute, so it is never checked against the blocked list. Proof of Concept --- Impact This vulnerability allows attackers to escape the intended Python sandbox and execute arbitrary code with the privileges of the host process. An attacker can: Access sensitive data such as environment variables, API keys,…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The AgentOS deployment platform exposes a GET /api/agents endpoint that returns agent names, roles, and the first 100 characters of agent system instructions to any unauthenticated caller. The AgentOS FastAPI application has no authentication middleware, no API key validation, and defaults to CORS alloworigins=[""] with host="0.0.0.0", making every deployment network-accessible and queryable from any origin by default. Details The AgentOS.registerroutes() method at src/praisonai/praisonai/app/agentos.py:118 registers all routes on a plain FastAPI app with no authentication dependencies: The AgentAppConfig at src/praisonai-agents/praisonaiagents/app/config.py:12-55 has no authentication fields — no apikey, no authmiddleware, no tokensecret. The only middleware added is CORS with wildcard origins: Notably, the older apiserver.py:58 includes a checkauth() guard on its /agents endpoint, indicating the project is aware that authentication is required for agent listing endpoints.…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The gateway's /api/approval/allow-list endpoint permits unauthenticated modification of the tool approval allowlist when no authtoken is configured (the default). By adding dangerous tool names (e.g., shellexec, filewrite) to the allowlist, an attacker can cause the ExecApprovalManager to auto-approve all future agent invocations of those tools, bypassing the human-in-the-loop safety mechanism that the approval system is specifically designed to enforce. Details The vulnerability arises from the interaction of three components: 1. Authentication bypass in default config checkauth() in server.py:243-246 returns None (no error) when self.config.authtoken is falsy: GatewayConfig defaults authtoken to None (config.py:61): 2. Unrestricted allowlist modification The approvalallowlist handler at server.py:381-420 calls checkauth() and proceeds when it returns None: There is no validation that toolname corresponds to a real tool, no restriction on which tools can be allowlisted, and…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The WSGI-based recipe registry server (server.py) reads the entire HTTP request body into memory based on the client-supplied Content-Length header with no upper bound. Combined with authentication being disabled by default (no token configured), any local process can send arbitrarily large POST requests to exhaust server memory and cause a denial of service. The Starlette-based server (serve.py) has RequestSizeLimitMiddleware with a 10MB limit, but the WSGI server lacks any equivalent protection. Details The vulnerable code path in src/praisonai/praisonai/recipe/server.py: 1. No size limit on body read (line 551-555): The contentlength is taken directly from the HTTP header with no maximum check. The entire body is read into a single bytes object in memory. 2. Second in-memory copy via multipart parsing (line 169-172): The parsemultipart method splits the already-buffered body and stores file contents in a dict, creating additional in-memory copies. 3. Third copy to temp…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /media-stream WebSocket endpoint in PraisonAI's call module accepts connections from any client without authentication or Twilio signature validation. Each connection opens an authenticated session to OpenAI's Realtime API using the server's API key. There are no limits on concurrent connections, message rate, or message size, allowing an unauthenticated attacker to exhaust server resources and drain the victim's OpenAI API credits. Details The vulnerability exists in src/praisonai/praisonai/api/call.py. The FastAPI application defines a WebSocket endpoint at line 108 with no authentication middleware, no Twilio request signature validation, and no rate limiting: Immediately upon connection, the handler opens an authenticated session to OpenAI's paid Realtime API using the server's OPENAIAPIKEY: The receivefromtwilio() coroutine then reads unlimited messages and forwards them directly to OpenAI: The server binds to 0.0.0.0 (line 273) and can be exposed to the internet via…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
deploy.py constructs a single comma-delimited string for the gcloud run deploy --set-env-vars argument by directly interpolating openaimodel, openaikey, and openaibase without validating that these values do not contain commas. gcloud uses a comma as the key-value pair separator for --set-env-vars. A comma in any of the three values causes gcloud to parse the trailing text as additional KEY=VALUE definitions, injecting arbitrary environment variables into the deployed Cloud Run service. Grep Commands and Evidence Step 1. Confirm the vulnerable string construction at line 150 Expected output showing unsanitized interpolation: 150: '--set-env-vars', f'OPENAIMODELNAME={openaimodel},OPENAIAPIKEY={openaikey},OPENAIAPIBASE={openaibase}' Step 2. Confirm no comma validation exists before this line Expected output: no results related to input validation Step 3. View the full context of the vulnerable construction This block shows the gcloud command list where the three values are…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Flask API endpoint in src/praisonai/api.py renders agent output as HTML without effective sanitization. The sanitizehtml function relies on the nh3 library, which is not listed as a required or optional dependency in pyproject.toml. When nh3 is absent (the default installation), the sanitizer is a no-op that returns HTML unchanged. An attacker who can influence agent input (via RAG data poisoning, web scraping results, or prompt injection) can inject arbitrary JavaScript that executes in the browser of anyone viewing the API output. Details In src/praisonai/api.py, lines 6-14 define the sanitizer with a try/except ImportError fallback: The home() route at lines 21-25 converts agent output to HTML via markdown.markdown() (which preserves raw HTML tags by default) and embeds it in an HTML response using an f-string — bypassing Flask's Jinja2 auto-escaping: Since nh3 is not in any dependency list (pyproject.toml core deps, optional deps, or requirements files), a standard…
Recommended action: Upgrade to 4.5.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The executecommand function and workflow shell execution are exposed to user-controlled input via agent workflows, YAML definitions, and LLM-generated tool calls, allowing attackers to inject arbitrary shell commands through shell metacharacters. --- Description PraisonAI's workflow system and command execution tools pass user-controlled input directly to subprocess.run() with shell=True, enabling command injection attacks. Input sources include: 1. YAML workflow step definitions 2. Agent configuration files (agents.yaml) 3. LLM-generated tool call parameters 4. Recipe step configurations The shell=True parameter causes the shell to interpret metacharacters (;, |, &&, $(), etc.), allowing attackers to execute arbitrary commands beyond the intended operation. --- Affected Code Primary command execution (shell=True default): Workflow shell step execution: Action orchestrator shell execution: --- Input Paths to Vulnerable Code Path 1: YAML Workflow Definition Users define workflows in…
Recommended action: Upgrade to 4.5.121 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Direct insertion of unescaped user input into template-rendering tools allows arbitrary code execution via specially crafted agent instructions. Details The createagentcentrictools() function returns tools (like acpcreatefile) that process file content using template rendering. When user input from agent.start() is passed directly into these tools without escaping (as shown in agentcentricexample.py:85-86), template expressions in the input are executed rather than treated as literal text. This occurs because: 1. No input sanitization or escaping is applied to user-controlled content 2. The ACP-enabled runtime auto-approves operations (approvalmode="auto") 3. Tools lack context-aware escaping for template syntax PoC Successful exploitation creates /tmp/pwned confirming arbitrary command execution. The expression {{77}} renders as 49 instead of literal text. Impact Attackers can execute arbitrary system commands with the privileges of the running process by injecting malicious…
Recommended action: Upgrade to 4.5.115 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The A2U (Agent-to-User) event stream server in PraisonAI exposes all agent activity without authentication. This is a separate component from the gateway server fixed in CVE-2026-34952. The createa2uroutes() function registers the following endpoints with NO authentication checks: - GET /a2u/info — exposes server info and stream names - POST /a2u/subscribe — creates event stream subscription - GET /a2u/events/{streamname} — streams ALL agent events - GET /a2u/events/sub/{id} — streams events for subscription - GET /a2u/health — health check An unauthenticated attacker can: 1. POST /a2u/subscribe → receive subscriptionid 2. GET /a2u/events/sub/{subscriptionid} → receive live SSE stream of all agent events including responses, tool calls, and thinking This exposes sensitive agent activity including responses, internal reasoning, and tool call arguments to any network attacker. <img width="1512" height="947" alt="image"…
Recommended action: Upgrade to 4.5.115 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The AgentService.loadAgentFromFile method uses the js-yaml library to parse YAML files without disabling dangerous tags (such as !!js/function and !!js/undefined). This allows an attacker to craft a malicious YAML file that, when parsed, executes arbitrary JavaScript code. An attacker can exploit this vulnerability by uploading a malicious agent definition file via the API endpoint, leading to remote code execution (RCE) on the server. Details The vulnerability exists in the YAML deserialization process. The js-yaml library's load function is used without specifying a safe schema (e.g., JSONSCHEMA or DEFAULTSAFESCHEMA). This enables the parsing of JavaScript functions and other dangerous types. When a malicious YAML file containing a !!js/function tag is parsed, the function is evaluated, leading to arbitrary code execution. The vulnerable code is located in src/agents/agent.service.ts at line 55. PoC An attacker can create a malicious agent YAML file with the following…
Recommended action: Upgrade to 4.5.115 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Executive Summary: The path validation has a critical logic bug: it checks for .. AFTER normpath() has already collapsed all .. sequences. This makes the check completely useless and allows trivial path traversal to any file on the system. The path validation function also does not resolve the symlink wich could potentially cause path traversal. Details: validatepath() calls os.path.normpath() first, which collapses .. sequences, then checks for '..' in normalized. Since .. is already collapsed, the check always passes. Vulnerable File: src/praisonai-agents/praisonaiagents/tools/filetools.py Lines: 42-49 Severity: CRITICAL CVSS v3.1: 9.2 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Proof of concept (PoC) Prerequisites: - Ability to specify a file path can call file operations Steps to reproduce: poc.py Why this works: Impact: - Complete bypass of path traversal protection -…
Recommended action: Upgrade to 1.5.113 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI's recipe registry publish endpoint writes uploaded recipe bundles to a filesystem path derived from the bundle's internal manifest.json before it verifies that the manifest name and version match the HTTP route. A malicious publisher can place ../ traversal sequences in the bundle manifest and cause the registry server to create files outside the configured registry root even though the request is ultimately rejected with HTTP 400. This is an arbitrary file write / path traversal issue on the registry host. It affects deployments that expose the recipe registry publish flow. If the registry is intentionally run without a token, any network client that can reach the service can trigger it. If a token is configured, any user with publish access can still exploit it. Details The bug is caused by the order of operations between the HTTP handler and the registry storage layer. 1. RegistryServer.handlepublish() in src/praisonai/praisonai/recipe/server.py:370-426 parses…
Recommended action: Upgrade to 4.5.113 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PraisonAI's recipe registry pull flow extracts attacker-controlled .praison tar archives with tar.extractall() and does not validate archive member paths before extraction. A malicious publisher can upload a recipe bundle that contains ../ traversal entries and any user who later pulls that recipe will write files outside the output directory they selected. This is a path traversal / arbitrary file write vulnerability on the client side of the recipe registry workflow. It affects both the local registry pull path and the HTTP registry pull path. The checksum verification does not prevent exploitation because the malicious traversal payload is part of the signed bundle itself. Details The issue is caused by unsafe extraction of tar archive contents during recipe pull. 1. A malicious publisher creates a valid .praison bundle whose manifest.json is benign enough to pass publish, but whose tar members include traversal entries such as: 2. LocalRegistry.publish() in…
Recommended action: Upgrade to 4.5.113 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Action Orchestrator feature contains a Path Traversal vulnerability that allows an attacker (or compromised agent) to write to arbitrary files outside of the configured workspace directory. By supplying relative path segments (../) in the target path, malicious actions can overwrite sensitive system files or drop executable payloads on the host. Details Location: src/praisonai/praisonai/cli/features/actionorchestrator.py (Lines 402, 409, 423) Vulnerable Code snippet: In the applystep method, paths are constructed by concatenating the workspace path with a user-supplied step.target string: target = workspace / step.target. The code fails to resolve and validate that the final absolute path remains within the bounds of the workspace directory. When processing FILECREATE or FILEEDIT actions, this flaw permits arbitrary file modification. PoC Construct a malicious ActionStep payload with path traversal characters: Impact This is an Arbitrary File Write vulnerability. Anyone running…
Recommended action: Upgrade to 4.5.113 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PraisonAI templates installation feature is vulnerable to a "Zip Slip" Arbitrary File Write attack. When downloading and extracting template archives from external sources (e.g., GitHub), the application uses Python's zipfile.extractall() without verifying if the files within the archive resolve outside of the intended extraction directory. Details Location: src/praisonai/praisonai/cli/features/templates.py (Line 852) Vulnerable Code snippet: During installation, the CLI downloads a ZIP archive and extracts it directly into a temporary directory using zipref.extractall(tmpdir). A specially crafted ZIP archive can contain file entries with relative paths (such as ../../../../tmp/evil.sh). If extracting this archive in older Python versions or environments where extraction rules aren't strict, extractall will write these files outside the target directory, allowing an attacker to overwrite arbitrary files on the victim's filesystem. PoC 1. Generate a malicious zip payload: 2. Trick…
Recommended action: Upgrade to 4.5.113 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OAuthManager.validatetoken() returns True for any token not found in its internal store, which is empty by default. Any HTTP request to the MCP server with an arbitrary Bearer token is treated as authenticated, granting full access to all registered tools and agent capabilities. Details oauth.py:364 (source) - oauth.py:374 (loop miss) - oauth.py:381 (sink) PoC Impact Any unauthenticated attacker with network access to the MCP HTTP server can call all registered tools including agent execution, workflow runs, container file read/write, and skill loading. The server binds to 0.0.0.0 by default with no API key required. Suggested Fix
Recommended action: Upgrade to 4.5.97 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PraisonAI Gateway server accepts WebSocket connections at /ws and serves agent topology at /info with no authentication. Any network client can connect, enumerate registered agents, and send arbitrary messages to agents and their tool sets. Details gateway/server.py:242 (source) - gateway/server.py:250 (sink) PoC Impact Any unauthenticated attacker with network access can connect to the WebSocket gateway, enumerate all registered agents via /info, and send arbitrary messages to agents including tool execution, file reads, and API calls. GatewayConfig has an authtoken field that is never enforced in the handler. Suggested Fix
Recommended action: Upgrade to 4.5.97 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.