CVE-2026-114140 in nbconvert
Summary
by MITRE • 10/21/2026
The nbconvert tool, jupyter nbconvert, converts Jupyter notebooks to various other formats via Jinja templates. From 5.4.0 until 7.17.2, ExtractOutputPreprocessor in nbconvert/preprocessors/extractoutput.py joins the attacker-controlled cell output metadata filename to output_files_dir without limiting the result to the intended directory. When a victim converts a malicious notebook with the markdown, LaTeX, reStructuredText, or AsciiDoc exporter, path traversal in the output filename can write attacker-controlled output data to arbitrary locations accessible to the victim. Running the notebook cell again replaces the malicious output metadata, but merely converting the supplied notebook does not. This issue is fixed in version 7.17.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Jupyter nbconvert represents a critical path traversal flaw within the ExtractOutputPreprocessor component, affecting versions from 5.4.0 through 7.17.2. Nbconvert serves as a primary utility for converting Jupyter notebooks into various static formats such as HTML, PDF via LaTeX, Markdown, reStructuredText, and AsciiDoc. The core function of this tool involves processing notebook cells and their associated metadata to generate the final output files. In this specific instance, the flaw resides in how the application handles filenames embedded within cell output metadata when preparing exports for markdown, LaTeX, restructured text, or asciidoc exporters.
The technical root cause is a failure to properly sanitize or validate user-supplied input before joining it with the intended output directory path. Specifically, the ExtractOutputPreprocessor takes an attacker-controlled filename from the notebook's metadata and concatenates it directly with the output_files_dir variable without enforcing strict boundary checks. This lack of validation allows for relative path traversal sequences, such as dot-dot-slash characters, to be interpreted by the underlying file system operations rather than being treated as literal string components. Consequently, instead of writing a generated asset like an image or data file into the designated export folder, the application writes it to any arbitrary location on the local filesystem that is accessible to the user executing the conversion process.
The operational impact of this vulnerability is significant because it enables unauthorized file system access and potential remote code execution depending on the context in which nbconvert is run. An attacker can craft a malicious Jupyter notebook containing specially crafted cell output metadata with path traversal sequences. When an unsuspecting victim opens or converts this notebook using one of the affected exporters, the tool will inadvertently write files to arbitrary directories. This could lead to overwriting critical system configuration files, injecting web shells if the target directory is served by a web server, or exfiltrating sensitive data by writing it to locations where other processes might read them. The vulnerability persists even after closing and reopening the notebook because the malicious metadata remains embedded in the file structure until explicitly corrected; however, the actual exploitation occurs during the conversion process itself rather than merely upon viewing the notebook.
This flaw aligns with Common Weakness Enumeration CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes scenarios where software does not properly validate input paths before using them in file operations. From an offensive security perspective, this behavior is consistent with ATT&CK technique T1048: Exfiltration Over Alternative Protocol or potentially T1567: Steal Web Session Cookie if the written files are used to manipulate session states, though primarily it facilitates unauthorized data access and modification as described in T1223: Obfuscated Files or Information when considering how the malicious payload is hidden within standard notebook metadata. The vulnerability highlights a broader class of risks associated with processing untrusted documents that contain executable logic or embedded resources without rigorous sandboxing or input validation.
Mitigation for this issue involves upgrading to version 7.17.2 or later, where the developers have implemented proper path normalization and restriction mechanisms to ensure all output files remain within the intended directory boundaries. Organizations relying on Jupyter notebooks for data analysis should enforce strict policies regarding which notebooks are opened and converted, particularly those sourced from untrusted external parties. Additionally, running nbconvert with restricted file system permissions can limit the blast radius of such an attack by ensuring that even if a path traversal occurs, the attacker cannot write to critical system directories or sensitive user folders. Regular auditing of notebook sources and keeping dependencies updated are essential practices for maintaining security in data science environments where these tools are prevalent.