{“lastseen”:”2025-12-16T20:05:08″,”description”:”_After our research on_ _Cursor_ _, in the context of developer-ecosystem security, we turn our attention to the Jupyter ecosystem. We expose security risks we identified in the notebook\u2019s export functionality, in the default Windows environment, to help organizations better protect their assets and networks._\\n\\n## Executive Summary\\n\\nWe identified a new way external Jupyter notebooks could be exploited by threat actors to lure unsuspecting users and compromise their workstation.\\n\\nCompanies are recommended to use a centralized Jupyter server, stay up to date and strictly restrict external files susceptible to processing with Jupyter software.\\n\\n## Introduction\\n\\nJupyter notebook is quite an institution in the development of IA projects. Back in 2015, around 200,000 notebooks were publicly available on GitHub\u2014by early 2021 that number had surged to nearly 10 million. Used by more than 80 % of data scientists and AI engineers worldwide, Jupyter is deeply embedded in every stage of AI workflows, from exploratory analysis and visualization to model prototyping and collaboration.\\n\\nWhen investigating this ecosystem, our approach was to try to imagine where a threat actor could find his way through, and leverage functionalities to exploit victims\u2019 environments. The first direction came surprisingly easily: the configuration files.\\n\\nConfiguration files are often considered innocuous. However, they may include obscure parameters that most users aren\u2019t aware of. Ignoring them would be a critical mistake.\\n\\nConfig files have led to vulnerabilities in many other instances. For example, in VSCode\u2019s IDE, the .vscode\/settings.json config file was also a key component in multiple high severity vulnerabilities discovered (CVE\u20112021\u201134529 , CVE\u20112025\u201153773 or CVE-2025-54130).\\n\\nOne specificity of the Jupyter ecosystem that makes this attack vector even more interesting is the fact that configuration files are also perfectly valid Python executables- making them easier to exploit.\\n\\n## Jupyter Configuration Files\\n\\nThe most common configuration file is jupyter_notebook_config.py, typically found in the user-specific configuration directory (~\/.jupyter\/). It\u2019s responsible for defining core Notebook server settings such as network bindings, authentication options, file system paths, and various security-related parameters. However, other config files may also be used depending on the component, such as jupyter_nbconvert_config.py for export settings, or jupyter_server_config.py for Jupyter Server.\\n\\nConfiguration files can actually exist in any directory, allowing for layered overrides. Available options cover a wide range of functionality, from UI behavior and authentication to kernel management, export formats, logging, and more. This approach gives users fine-grained control over the entire Jupyter ecosystem.\\n\\nFor example:\\n \\n \\n c = get_config()\\n c.NotebookApp.port = 8888\\n c.FileContentsManager.save_script = True\\n\\nHowever, acknowledging a high severity impact, Jupyter decided in October 2022 to remove CWD from the config paths, reducing the risk presented significantly.\\n\\nThis was the starting point of our research. We started searching for a similar or stronger way to exploit the same idea: having a file whose name is not constrained adjacent to a jupyter notebook, assuming an unsuspecting user would trigger an _innocuous operation on a perfectly legit Jupyter notebook on the official Jupyter software_ and inadvertently allow full system compromise.\\n\\nAnd this is exactly what we found by investigating the official export tool of Jupyter, nbconvert.\\n\\n## The Vulnerability\\n\\nThe vulnerability we discovered allows arbitrary code execution on Windows machines when exporting a notebook to PDF. By placing a properly named, malicious script in the notebook folder location, an attacker could hijack the conversion process and execute code with the privileges of the user.\\n\\nWhen a Jupyter notebook containing SVG output is exported via nbconvert, the svg2pdf.py preprocessor is triggered to convert SVG images via the Inkscape tool. During this process, the path to Inkscape executable is resolved using Python\u2019s shutil.which() via the following expression:\\n \\n \\n inkscape_path = which(\\”inkscape\\”)\\n\\nwithout including inkscape anywhere as a mandatory nbconvert dependency. This opened the door to unintended code execution as the following figure shows:\\n\\n_Fig. 1: High level flow of exploitation of the security issue_\\n\\nshutil.which behavior is controlled internally by the Windows API function NeedCurrentDirectoryForExePathW, which returns TRUE (include CWD) when the NoDefaultCurrentDirectoryInExePath environment variable is not set, which is the default configuration on standard Windows installations.\\n\\nIn Python versions earlier than 3.12, `shutil.which()` ignores the `NoDefaultCurrentDirectoryInExePath` environment variable entirely, making it impossible to prevent this unsafe search behavior through configuration.\\n\\nPython 3.12 and later versions properly respect this environment variable when set, but the variable remains unset by default on Windows systems, leaving many vulnerable.\\n\\nSince nbconvert officially supports Python versions starting from 3.9, it includes versions that are affected by this issue both ways.\\n\\n## CVE-2025-53000\\n\\nThis unsafe lookup behavior aligns with CWE-427: Uncontrolled Search Path Element. Therefore, we recommended disabling the searching of inkscape software from CWD and relying on fixed safe search places.\\n\\nUpon receiving our report, the Jupyter team reproduced the issue, acknowledged the associated risk, and requested a CVE (see below). A discussion was then initiated regarding how to fix the issue. However, the Jupyter team eventually stopped responding to our messages and has not addressed the issue to date.\\n\\nCVE-2025-53000 has been assigned to this vulnerability. At the time of publication, the Github advisory has not yet been released by the maintainers.\\n\\nBecause export functionality is commonly used and generally trusted, it presents an attractive target for attackers, and especially in environments where notebooks are frequently shared\u2014such as academic research groups, data science teams, or educational institutions\u2014the potential for exploitation increases substantially.\\n\\nEventually, following our 90-day policy, we decided to publish this advisory to help protect the community.\\n\\n## Demonstration Video\\n\\nThe following demonstration video was recorded on a Windows 10 Enterprise x64 machine with default settings, using miniconda3 and Python 3.13.9, using the latest available Jupyter software versions, including:\\n\\nJupyter Core 5.9.1, nbconvert 7.16.6, and Notebook 7.5.0\\n\\nhttps:\/\/www.imperva.com\/blog\/wp-content\/uploads\/sites\/9\/2025\/12\/jupyter-nbconvert-poc.mp4\\n\\n## Post Exploitation\\n\\nOnce successfully triggered, this vulnerability gives the attacker arbitrary code-execution in the context of the user. This immediately impacts confidentiality, integrity, and availability, as the attacker can access, modify, or disrupt the user\u2019s data and workflows. On typical Windows data-science workstations, victim accounts almost always have:\\n\\n * Direct access to sensitive notebooks and datasets.\\n * Cached cloud credentials (AWS CLI, Azure CLI, gcloud, Databricks etc.)\\n * Locally installed package managers (conda, pip, winget) and DevOps pipelines that will happily run additional code.\\n\\n\\n\\nThis potentially amplifies the radius of compromise, allowing its effects to spread beyond the initial workstation.\\n\\n## Recommendations\\n\\nCompanies are recommended to rely on a centralized Jupyter server, ensure that all Jupyter-related software remains up to date, and enforce strict restrictions on external files that may be processed through Jupyter tools.\\n\\nIt is also recommended to enable the NoDefaultCurrentDirectoryInExePath environment variable to reduce the risk of unintentionally executing files from untrusted locations.\\n\\n## Conclusion\\n\\nThis vulnerability shows how the invisible glue of our workflows can become points of failure when not properly scrutinized.\\n\\nWe expect more vulnerabilities to surface in this fast-growing AI ecosystem as workflows become more automated, composable, and cloud-integrated, and we hope this report encourages teams to take a closer look at the quiet dependencies holding their environments together.\\n\\n## Timeline\\n\\n * June 8: Disclosure report submitted.\\n * June 12: Issue reproduced.\\n * June 25: CVE reservation by Jupyter team.\\n\\n\\n\\nThe post Code Execution in Jupyter Notebook Exports appeared first on Blog.”,”published”:”2025-12-16T19:43:28″,”modified”:”2025-12-16T19:43:28″,”type”:”impervablog”,”title”:”Code Execution in Jupyter Notebook Exports”,”source”:””,”references”:””,”id”:”IMPERVABLOG:AF8A846A09089C84E360221A65091766″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[“CVE-2021-34529″,”CVE-2025-53000″,”CVE-2025-53773″,”CVE-2025-54130″],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:9.8,”severity”:”CRITICAL”,”vector”:”CVSS:3.1\/AV:N\/AC:L\/PR:N\/UI:N\/S:U\/C:H\/I:H\/A:H”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.imperva.com\/blog\/code-execution-in-jupyter-notebook-exports\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-12-16T20:05:08″,”description”:”_After our research on_ _Cursor_ _, in the context of developer-ecosystem security, we turn our attention to the Jupyter ecosystem. We expose security risks we…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[9,6,8,35,12,59,13,7,11,5],"class_list":["post-31443","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-critical","tag-cve","tag-cvss","tag-cvss-98","tag-exploit","tag-impervablog","tag-news","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n