AI Threat Alertnbconvert, the Jupyter notebook conversion tool, has a path traversal flaw (CWE-22) in its ExtractOutputPreprocessor. A malicious notebook can carry a crafted output filename in cell metadata, and converting it to markdown, LaTeX, reStructuredText or AsciiDoc writes attacker-controlled data outside the intended output directory. Exposure is real for data science teams, MLOps pipelines and documentation or CI jobs that convert notebooks received from untrusted sources, such as shared repositories, vendor deliverables or public model cards. Severity is not yet scored, there is no CISA KEV listing, no EPSS data, no public exploit and no Nuclei template, so this is a patch-in-cycle item, not an emergency. Upgrade nbconvert to 7.17.2 or later, and until then avoid converting untrusted notebooks or run conversion in a sandboxed, low-privilege container.
What is the risk?
Medium, pending an official CVSS score. Exploitation needs a victim to convert an attacker-supplied notebook, so some user interaction or an automated pipeline ingesting untrusted content is required. Impact is arbitrary file write with the victim's privileges, but the attacker controls the output data and filename, not necessarily a full executable payload. It can still lead to code execution if files land in startup scripts, shell profiles, cron-like locations or Python site-packages paths. No known exploitation, no KEV listing, no public PoC. Affected versions span 5.4.0 through 7.17.1, a very wide range that likely covers many deployed environments.
How does the attack unfold?
What systems are affected?
How severe is it?
What should I do?
1 step1) Upgrade nbconvert to 7.17.2 or later (pip install -U nbconvert) across workstations, JupyterHub images, CI runners and container base images. 2) Inventory with pip list or SBOM tooling for nbconvert versions 5.4.0 to 7.17.1, including transitive installs via jupyter, notebook and JupyterLab. 3) Until patched, do not convert notebooks from untrusted sources; run conversions in an ephemeral, network-restricted container with a read-only filesystem except the intended output directory, running as a non-root user. 4) Inspect notebooks before conversion by scanning cell output metadata for filenames containing '..' or absolute paths. 5) Detection: monitor for file writes by nbconvert processes outside the declared output directory and for unexpected changes to shell profiles, startup scripts and site-packages.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-114140?
nbconvert, the Jupyter notebook conversion tool, has a path traversal flaw (CWE-22) in its ExtractOutputPreprocessor. A malicious notebook can carry a crafted output filename in cell metadata, and converting it to markdown, LaTeX, reStructuredText or AsciiDoc writes attacker-controlled data outside the intended output directory. Exposure is real for data science teams, MLOps pipelines and documentation or CI jobs that convert notebooks received from untrusted sources, such as shared repositories, vendor deliverables or public model cards. Severity is not yet scored, there is no CISA KEV listing, no EPSS data, no public exploit and no Nuclei template, so this is a patch-in-cycle item, not an emergency. Upgrade nbconvert to 7.17.2 or later, and until then avoid converting untrusted notebooks or run conversion in a sandboxed, low-privilege container.
Is CVE-2026-114140 actively exploited?
No confirmed active exploitation of CVE-2026-114140 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-114140?
1) Upgrade nbconvert to 7.17.2 or later (pip install -U nbconvert) across workstations, JupyterHub images, CI runners and container base images. 2) Inventory with pip list or SBOM tooling for nbconvert versions 5.4.0 to 7.17.1, including transitive installs via jupyter, notebook and JupyterLab. 3) Until patched, do not convert notebooks from untrusted sources; run conversions in an ephemeral, network-restricted container with a read-only filesystem except the intended output directory, running as a non-root user. 4) Inspect notebooks before conversion by scanning cell output metadata for filenames containing '..' or absolute paths. 5) Detection: monitor for file writes by nbconvert processes outside the declared output directory and for unexpected changes to shell profiles, startup scripts and site-packages.
What systems are affected by CVE-2026-114140?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, notebook environments, MLOps CI/CD pipelines, experiment reporting and documentation pipelines.
What is the CVSS score for CVE-2026-114140?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001AI SoftwareAML.T0011.000Unsafe AI ArtifactsAML.T0037Data from Local SystemCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker publishes a notebook on a public repository or shares it as a 'reproducible research' artifact, with a cell output whose metadata filename is set to a traversal path such as ../../.bashrc or a path into a Python startup directory. A data scientist or an automated documentation pipeline converts the notebook to markdown. The preprocessor writes the attacker's output data to the traversal target outside the output directory. On the next shell login or interpreter startup, the planted content runs, giving the attacker code execution on the ML workstation or CI runner and access to datasets, model artifacts and cloud credentials.
Weaknesses (CWE)
CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')PrimaryCWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')PrimaryCWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
- [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2023-2557410.0JupyterHub LTI13: JWT forgery enables full auth bypass
Same package: jupyterCVE-2026-441809.8Jupyter Enterprise Gateway: root privilege bypass in Kubernetes
Same package: jupyterCVE-2026-235379.1Feast: unauth file write to RCE via /save-document
Same package: jupyterCVE-2026-545279.0jupyterlab-git: stored XSS escalates to full RCE
Same package: jupyterCVE-2026-447279.0jupyter-server: stored XSS yields kernel RCE
Same package: jupyter