CVE-2026-44727
Summary
by MITRE • 06/23/2026
Jupyter Server is the backend for Jupyter web applications. Prior to 2.20, the nbconvert HTTP handlers in jupyter_server render user-authored notebook HTML under the Jupyter origin without a sandbox directive in their Content-Security-Policy. Combined with nbconvert.HTMLExporter's default non-sanitizing behavior, a notebook carrying an HTML payload in a display_data output triggers stored XSS with cookie access, full /api/* authority, and kernel RCE. This vulnerability is fixed in 2.20.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/23/2026
The Jupyter Server serves as the foundational backend for various web-based Jupyter applications including JupyterLab and Jupyter Notebook interfaces. This system facilitates interactive computing environments where users can create, edit, and execute code notebooks containing both code cells and output data. The vulnerability under discussion affects versions prior to 2.20 and stems from a critical security flaw in how the server handles notebook conversion and rendering operations. When users upload or process notebooks through the nbconvert functionality, the system fails to properly sanitize HTML content within display_data outputs, creating an environment where malicious payloads can be executed without proper origin validation.
The technical implementation of this vulnerability involves multiple layers of security failure within the Jupyter Server architecture. The nbconvert HTTP handlers specifically lack a sandbox directive in their Content-Security-Policy headers, which should normally prevent untrusted content from executing within the browser context of the application. This absence allows HTML content generated by nbconvert.HTMLExporter to run under the trusted Jupyter origin domain rather than being isolated in a secure sandbox environment. The default behavior of HTMLExporter is particularly problematic as it does not sanitize user-authored content, leaving any embedded malicious scripts directly executable when rendered in the browser. This combination creates a perfect storm for stored cross-site scripting attacks where an attacker can embed malicious code within a notebook's display_data section that executes every time the notebook is viewed.
The operational impact of this vulnerability extends far beyond simple XSS exploitation and represents a complete compromise of the Jupyter Server environment. When a malicious notebook is processed and rendered, the stored XSS payload gains access to the user's browser session cookies, effectively allowing attackers to hijack authentication tokens and impersonate legitimate users. More critically, the vulnerability provides full authority over the /api/* endpoints which exposes the entire Jupyter server API interface including kernel management capabilities. This level of access enables attackers to execute arbitrary code on the server through kernel RCE (Remote Code Execution) capabilities, potentially leading to complete system compromise. The severity is amplified by the fact that this vulnerability can be triggered simply by viewing a malicious notebook, making it particularly dangerous in collaborative environments where users regularly share notebooks with each other.
The underlying technical weakness aligns with CWE-79 (Cross-site Scripting) and CWE-116 (Improper Encoding or Escaping of Output) classifications, representing a classic case of insufficient input sanitization combined with inadequate output encoding. From an ATT&CK framework perspective, this vulnerability maps to T1059 (Command and Scripting Interpreter) and T1078 (Valid Accounts) as attackers can leverage the compromised session to execute commands and maintain persistent access. The fix implemented in version 2.20 addresses these issues by properly configuring Content-Security-Policy headers with sandbox directives, implementing proper HTML sanitization for nbconvert outputs, and ensuring that user-generated content cannot execute within the trusted application context. Organizations should immediately upgrade to version 2.20 or later and consider implementing additional monitoring for suspicious notebook uploads and rendering activities as a defensive measure against potential exploitation attempts.
This vulnerability serves as a critical reminder of the importance of proper security controls in web applications that process user-generated content, particularly those with elevated privileges and API access capabilities. The combination of inadequate CSP configuration with unsafe HTML processing creates a pathway for attackers to escalate privileges from simple session hijacking to full system compromise, highlighting the need for comprehensive security testing and validation of all user input processing components within web applications.