Jupyter Server fixes stored XSS in nbconvert HTML rendering
Jupyter Server disclosed and fixed a stored cross-site scripting flaw in NbconvertFileHandler and NbconvertPostHandler that affects versions up to and including 2.19.0. The issue stems from nbconvert endpoints rendering user-authored notebook HTML under the Jupyter origin without a sandbox directive in the Content-Security-Policy, while nbconvert.HTMLExporter does not sanitize HTML by default. An attacker can place malicious HTML in notebook display_data output and trigger script execution when an authenticated user opens /nbconvert/html/<path>.
Successful exploitation could expose tokens and cookies, grant access to Jupyter /api/* endpoints, and potentially enable remote code execution through kernels. The project addressed the issue in jupyter-server 2.20.0 by adding sandbox allow-scripts to the CSP header for rendered nbconvert HTML in both GET and POST handlers, isolating any JavaScript in a unique origin. The mitigation is enabled by default through the new ServerApp.nbconvert_csp_sandbox setting, and the change is documented and covered by tests; a configuration-based workaround is also available for deployments that cannot easily patch source files.
Get ahead of threats like this
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
How this story unfolded
1 event from the most recent confirmed update back to the earliest known activity.
Jupyter Server fixes stored XSS in v2.20.0
A security advisory disclosed a stored cross-site scripting vulnerability in Jupyter Server nbconvert handlers affecting versions up to and including 2.19.0. The issue was fixed in Jupyter Server v2.20.0 by adding a Content-Security-Policy sandbox directive for rendered nbconvert HTML, with a new configuration option controlling the behavior.
Sources
2 references tracked. Mallory keeps watching after this page renders.
Merge commit from fork · jupyter-server/jupyter_server@6cbee8d · GitHub
github.com
Open sourceStored XSS in `NbconvertFileHandler` / `NbconvertPostHandler` via missing `sandbox` CSP · Advisory · jupyter-server/jupyter_server · GitHub
github.com
Open sourceSee the full picture, correlated to your attack surface.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Related stories
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Unauthorized Code Execution via Jupyter nbconvert Export on Windows
A critical vulnerability has been identified in the *nbconvert* tool, specifically affecting Jupyter environments on Windows. When converting a notebook containing SVG output to PDF using `jupyter nbconvert --to pdf`, the tool may inadvertently execute a malicious `inkscape.bat` file if present in the working directory, leading to unauthorized code execution. This flaw, tracked as CVE-2025-53000, impacts all versions up to and including 7.16.6, and currently, no official patch is available. The vulnerability is not remotely exploitable but poses a significant risk if an attacker can place a crafted batch file in a directory where a user performs notebook exports. Security researchers have highlighted the broader risks associated with Jupyter notebook export functionality, emphasizing how threat actors could exploit external notebooks to compromise user workstations. The research underscores the importance of securing Jupyter environments, recommending the use of centralized servers, regular updates, and strict controls over external files processed by Jupyter software. The attack vector leverages the fact that configuration files in Jupyter are valid Python executables, making them particularly susceptible to exploitation if not properly managed.
Mar 21, 2026
Stored XSS in sanitize-html Defaults via Disallowed `xmp` Tag Bypass
A vulnerability tracked as **CVE-2026-44990** allows stored cross-site scripting in `sanitize-html` when applications use the library’s default configuration and later render sanitized user content as trusted HTML. The flaw affects versions prior to **2.17.4** and stems from the handling of the disallowed `xmp` element: because `htmlparser2` treats `xmp` as a raw-text tag, attacker-supplied markup inside it is preserved as text during sanitization but can be emitted back as active HTML or JavaScript under the default `disallowedTagsMode: 'discard'` behavior. GitHub’s advisory and the upstream patch say the bypass can let payloads such as `<script>`, `img` event handlers, and `svg`-embedded script content survive filtering and execute in a victim’s browser. The fix in **2.17.4** adds `xmp` to `nonTextTags` so content inside a disallowed `xmp` tag is dropped instead of re-emitted, and regression tests were added to confirm the malicious content is removed. The issue was reported by **Vincenzo Turturro** (`sushi-gif`), and users of affected `sanitize-html` deployments, including those in **ApostropheCMS**, were urged to update immediately.
Jun 13, 2026
Authenticated Sandbox-Escape RCE Vulnerabilities in n8n Workflow Automation
JFrog researchers disclosed two vulnerabilities in the *n8n* workflow automation platform that allow an **authenticated** attacker to escape built-in sandboxes and achieve **remote code execution (RCE)** on the main n8n node, potentially leading to full instance compromise and access to sensitive connected systems (e.g., APIs, credentials, and internal tooling). The issues are tracked as **CVE-2026-1470** (CVSS **9.9**) and **CVE-2026-0863** (CVSS **8.5**); exploitation is possible even in configurations where n8n runs in “internal” execution mode, which n8n documentation already warns is risky for production due to weaker isolation between the application and task runner processes. Technical details indicate both flaws are sandbox escapes driven by language/runtime edge cases: **CVE-2026-1470** abuses JavaScript expression sandboxing (including `with`-statement handling) to resolve a constructor path to `Function` and execute arbitrary JavaScript, while **CVE-2026-0863** escapes the Python task executor sandbox via Python introspection and runtime behavior (notably Python 3.10+ `AttributeError.obj`) to regain access to restricted builtins/imports and execute OS commands. Recommended remediation is to upgrade n8n to fixed versions (for **CVE-2026-1470**: `1.123.17`, `2.4.5`, or `2.5.1`; for **CVE-2026-0863**: `1.123.14`, `2.3.5`, or `2.4.2`).
Mar 21, 2026