GHSA-pppj-hq3g-57pj: Jupyter — HIGH

JupyterLab 4.5+ allows notebook settings to be shared and applied through an `overrides.json` file using the `Import` button in the Settings Editor. Certain notebook display settings were not properly validated before being applied. As a result, a crafted settings file could contain hidden...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	>= 4.6.0, <= 4.6.1	`4.6.2`
13.2K OpenSSF 5.8 1.9K dependents Pushed 7d ago 56% patched ~28d to patch Full package profile →

Do you use Jupyter? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What should I do?

Patch available

Update Jupyter to version 4.6.2

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-pppj-hq3g-57pj?

JupyterLab 4.5+ allows notebook settings to be shared and applied through an `overrides.json` file using the `Import` button in the Settings Editor. Certain notebook display settings were not properly validated before being applied. As a result, a crafted settings file could contain hidden instructions that run as code inside JupyterLab when imported, instead of only changing a display preference. Because importing a settings file appears harmless, a user could import a file shared by another party without realizing it could do more. On multi-tenant file systems without proper permission control, another user could plant a malicious `overrides.json`. > CVE assignment pending, GitHub CNA is experiencing severe backlog ### Impact When a malicious settings file is applied, the embedded code runs with the same access as the affected user. This could allow an attacker to read or modify that user's notebooks and files, and to run code on the user's behalf through the notebook server, including on any connected kernel. #### User Interaction vs Privileges Required ##### Write access to a loaded settings location If an attacker can write to a directory JupyterLab loads settings from (e.g. on shared or multi-tenant file system), they could place a crafted `overrides.json` that is applied to another user automatically at startup. This requires high privilages but no action by the victim. ##### User-imported settings file A user can import a crafted `overrides.json` through the `Import` button in the Settings Editor, having received it from another party. This requires no privileges but a deliberate action by the victim, who reasonably expects a settings file to change preferences rather than run code. ### Patches JupyterLab 4.6.2 and 4.5.10 were patched. ### Workarounds None ### Hardening 1. Treat a settings file as something that can affect how JupyterLab behaves, not only how it appears. Administrators are encouraged to establish a trusted process for distributing configuration rather than relying on ad-hoc importing of shared files. 2. On multi-tenant or shared file systems, restrict write permissions on the application settings directory and other Jupyter configuration paths so that one user cannot place an `overrides.json` (or other configuration) readable by another user. A settings file in these locations is applied automatically, without an import step, so directory permissions are the primary control against cross-user tampering.

Is GHSA-pppj-hq3g-57pj actively exploited?

No confirmed active exploitation of GHSA-pppj-hq3g-57pj has been reported, but organizations should still patch proactively.

How to fix GHSA-pppj-hq3g-57pj?

Update to patched version: Jupyter 4.6.2.

What is the CVSS score for GHSA-pppj-hq3g-57pj?

No CVSS score has been assigned yet.

What are the technical details?

Original Advisory

JupyterLab 4.5+ allows notebook settings to be shared and applied through an `overrides.json` file using the `Import` button in the Settings Editor. Certain notebook display settings were not properly validated before being applied. As a result, a crafted settings file could contain hidden instructions that run as code inside JupyterLab when imported, instead of only changing a display preference. Because importing a settings file appears harmless, a user could import a file shared by another party without realizing it could do more. On multi-tenant file systems without proper permission control, another user could plant a malicious `overrides.json`. > CVE assignment pending, GitHub CNA is experiencing severe backlog ### Impact When a malicious settings file is applied, the embedded code runs with the same access as the affected user. This could allow an attacker to read or modify that user's notebooks and files, and to run code on the user's behalf through the notebook server, including on any connected kernel. #### User Interaction vs Privileges Required ##### Write access to a loaded settings location If an attacker can write to a directory JupyterLab loads settings from (e.g. on shared or multi-tenant file system), they could place a crafted `overrides.json` that is applied to another user automatically at startup. This requires high privilages but no action by the victim. ##### User-imported settings file A user can import a crafted `overrides.json` through the `Import` button in the Settings Editor, having received it from another party. This requires no privileges but a deliberate action by the victim, who reasonably expects a settings file to change preferences rather than run code. ### Patches JupyterLab 4.6.2 and 4.5.10 were patched. ### Workarounds None ### Hardening 1. Treat a settings file as something that can affect how JupyterLab behaves, not only how it appears. Administrators are encouraged to establish a trusted process for distributing configuration rather than relying on ad-hoc importing of shared files. 2. On multi-tenant or shared file systems, restrict write permissions on the application settings directory and other Jupyter configuration paths so that one user cannot place an `overrides.json` (or other configuration) readable by another user. A settings file in these locations is applied automatically, without an import step, so directory permissions are the primary control against cross-user tampering.

Weaknesses (CWE)

CWE-116 Improper Encoding or Escaping of Output Primary CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Primary

CWE-116 — Improper Encoding or Escaping of Output: The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error. Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.

Source: MITRE CWE corpus.