Server-Side - CraftedSignal Threat Feed

Jupyter Server Stored XSS via Missing CSP Sandbox (CVE-2026-44727)

hello@craftedsignal.io — Thu, 18 Jun 2026 15:20:33 +0000

Jupyter Server, versions up to 2.19.0, is affected by a critical stored Cross-Site Scripting (XSS) vulnerability, identified as CVE-2026-44727. This flaw resides in the NbconvertFileHandler and NbconvertPostHandler components, specifically due to a missing sandbox directive in their Content-Security-Policy (CSP). This oversight allows user-authored Jupyter notebooks containing malicious HTML payloads within display_data output to be rendered without proper sanitization or isolation. An authenticated attacker can craft such a notebook and share it. When an unsuspecting, authenticated victim navigates to the malicious notebook's output via the /nbconvert/html/ endpoint, the embedded script executes within their browser under the Jupyter origin. This grants the attacker potential access to the victim's authentication tokens, leading to cookie exfiltration, and can be escalated to full /api/* authority and kernel Remote Code Execution (RCE) on the server. This vulnerability poses a significant risk to the integrity and confidentiality of data on affected Jupyter environments.

Attack Chain

Attacker Crafts Malicious Jupyter Notebook: An authenticated attacker creates a Jupyter notebook containing a specially crafted HTML payload within a display_data output cell, embedding malicious JavaScript.
Attacker Uploads/Shares Notebook: The attacker uploads this malicious notebook to a vulnerable jupyter_server instance (versions up to 2.19.0) or shares it with potential victims.
Victim Accesses Server: An authenticated victim logs into the jupyter_server instance.
Triggering XSS: The victim navigates their browser to the malicious notebook's output view, which is rendered via the /nbconvert/html/ endpoint handled by NbconvertFileHandler or NbconvertPostHandler.
Vulnerable Rendering: The jupyter_server renders the user-authored HTML content. Due to the missing sandbox directive in the Content-Security-Policy, the malicious HTML is not isolated and executes without restrictions.
Client-Side Execution: The embedded malicious JavaScript executes within the victim's browser, operating under the same origin as the jupyter_server.
Token Exfiltration: The executing script accesses the victim's authentication tokens (e.g., cookies, session tokens) and exfiltrates them to an attacker-controlled domain.
Kernel RCE: Leveraging the victim's authenticated session, the script utilizes full /api/* authority to interact with Jupyter's internal APIs, potentially achieving Remote Code Execution on the Jupyter kernel or the underlying server.

Impact

The successful exploitation of CVE-2026-44727 can lead to severe consequences for affected jupyter_server instances. An authenticated victim's session tokens, including cookies, can be exfiltrated to an attacker-controlled domain, compromising user accounts and sensitive data. Furthermore, the malicious script executing with full /api/* authority can be used to interact with the Jupyter environment, potentially achieving kernel Remote Code Execution (RCE). This allows an attacker to execute arbitrary commands on the server hosting the Jupyter kernel, leading to data theft, system compromise, or further network penetration. The vulnerability impacts any organization or individual using jupyter_server for data analysis, development, or educational purposes, especially in collaborative environments where users might share notebooks.

Recommendation

Immediately patch jupyter_server to version v2.20.0 or higher to address CVE-2026-44727.
For deployments where patching is impractical, implement the provided workaround by adding the Content-Security-Policy modification to your jupyter_server_config.py file.
Deploy the Sigma rules "Detects CVE-2026-44727 Exploitation — Jupyter nbconvert HTML Handler Access" and "Detects CVE-2026-44727 Probing — Suspicious Characters in Jupyter nbconvert Path" to your SIEM for monitoring.
Ensure webserver logs are collected and ingested into your security monitoring platform to enable detection of these activities.

npm PraisonAI SandboxExecutor allowedCommands bypass via shell chaining

hello@craftedsignal.io — Thu, 18 Jun 2026 15:04:55 +0000

The npm:praisonai package, which provides "safe command execution with restrictions" via its SandboxExecutor and CommandValidator components, contains a critical vulnerability affecting versions 1.2.3 through 1.7.1. The CommandValidator component incorrectly processes command strings when allowedCommands is configured: it only checks the first whitespace-delimited token for allowlisting, while the SandboxExecutor subsequently passes the entire, unmodified command string to spawn("sh", ["-c", command]). This discrepancy allows attackers to append arbitrary shell commands using metacharacters (e.g., ;, &&, ||) after an allowlisted initial command, bypassing the intended security controls. This allows for arbitrary code execution with the privileges of the PraisonAI process if lower-trust input (such as user prompts or model output) is processed by the vulnerable component. The vulnerability is present in src/praisonai-ts/src/cli/features/sandbox-executor.ts and confirmed in distributed npm:praisonai@1.7.1 files.

Attack Chain

An attacker crafts a malicious command string that begins with an allowlisted command (e.g., echo) followed by shell metacharacters and arbitrary commands (e.g., echo allowed; cat /tmp/marker).
This malicious command string is supplied as input to an application, CLI tool, or agent pipeline that utilizes the npm:praisonai library's SandboxExecutor or sandboxExec function.
The CommandValidator component within praisonai receives the command string and checks its allowedCommands policy by extracting only the first whitespace-delimited token (e.g., echo).
If the first token matches an entry in the allowedCommands list, the CommandValidator incorrectly deems the entire command string valid and permits its execution.
The SandboxExecutor proceeds to invoke spawn('sh', ['-c', malicious_command_string]), passing the full, unvalidated string directly to the system shell.
The sh process interprets the shell metacharacter (e.g., ;) as a command separator, executing both the initially allowlisted command and the subsequent arbitrary malicious commands (e.g., cat /tmp/marker).
The attacker achieves arbitrary command execution with the privileges of the PraisonAI process, enabling actions such as reading or modifying files, invoking local tools, or causing denial of service.

Impact

The successful exploitation of this vulnerability allows for arbitrary shell command execution within the context of the PraisonAI process. Depending on the privileges of the hosting application and the affected system, this can lead to severe consequences, including unauthorized access to sensitive data (confidentiality), modification or deletion of critical files (integrity), and disruption of service (availability). If the PraisonAI application handles lower-trust input, such as from user prompts or AI model outputs, the risk of compromise is significantly elevated. While the advisory notes a local-only proof-of-concept, the nature of the vulnerability means that any application exposing SandboxExecutor's functionality to external input could be at risk.

Recommendation

Upgrade npm:praisonai to a patched version once available. Monitor the official GitHub advisory GHSA-vjv9-7m7j-h833 for release information.
Deploy the provided Sigma rule "Detect Suspicious sh -c Spawns by Node.js with Shell Chaining" to your SIEM system to identify attempts at exploiting this vulnerability.
Enable comprehensive process_creation logging on all Linux systems running Node.js applications that might utilize npm:praisonai or similar command execution libraries.
Review applications using npm:praisonai versions >= 1.2.3, <= 1.7.1 to ensure that any input passed to SandboxExecutor or sandboxExec is strictly validated and sanitized, avoiding shell metacharacters.
As a temporary mitigation, if direct patching is not immediately feasible, consider implementing input sanitization at the application layer to strip or escape shell metacharacters before passing commands to npm:praisonai functions.