CVE-2026-73417: settings CSS injection leads to

CISO Take

JupyterLab's Settings Editor lets users import an overrides.json file to customize the interface, but two margin-override fields aren't sanitized before being inserted into style content — a crafted file executes arbitrary code instead of just changing layout, and that code runs with the victim's full access to notebooks, files, and the connected kernel. This matters most for organizations running JupyterHub or other shared Jupyter deployments, where an attacker who can plant a file in a shared settings location doesn't need the victim to click anything at all. The immediate exploitation risk is low — EPSS sits at 0.55% (roughly median, top 56th percentile), the CVE isn't in CISA's KEV catalog, CISA's own SSVC decision is TRACK (lowest priority), and there's no public PoC or Nuclei template yet — but the impact ceiling is high given code execution reaches the kernel where credentials, training data, and model artifacts often live. Patch to JupyterLab 4.5.10 or 4.6.2 now; if you can't patch immediately, lock down write access to shared settings paths in multi-tenant deployments and tell users not to import overrides.json files from untrusted sources.

Sources:NVDGitHub AdvisoryEPSSCISA KEVATLAS

What is the risk?

Low near-term exploitation probability but meaningful blast radius in shared environments. EPSS (0.55%, ~56th percentile) and the absence of KEV listing, public exploit code, or a Nuclei template all point to no active exploitation. CISA's SSVC decision of TRACK confirms this is not an emergency-patch scenario for typical single-user installs. However, the requirement for user interaction (or a writable shared settings path) is a meaningful but not high barrier — in JupyterHub/multi-tenant research and education deployments where home directories or shared volumes are writable by multiple users, an attacker doesn't need social engineering at all, just file placement. Given the ai_tool categorization and JupyterLab's ubiquity as the default IDE for data scientists and ML engineers, treat this as moderate risk with priority patching for any shared/hosted JupyterLab deployment.

How does the attack unfold?

Malicious file delivery

Attacker crafts an overrides.json with a malicious CSS payload in the margin-override settings and delivers it via social engineering or plants it in a shared/writable settings location.

AML.T0011.000

Import / auto-apply

Victim imports the file via the Settings Editor's Import button, or JupyterLab auto-applies it from a shared settings path.

AML.T0011

Code execution in frontend

Unsanitized override values are injected into style content, executing attacker script inside the victim's JupyterLab session.

AML.T0050

Kernel and data compromise

The executed code abuses the victim's authenticated session to call the notebook server API, read/modify notebooks and files, and run arbitrary code on the connected kernel.

AML.T0037

Malicious file delivery

Attacker crafts an overrides.json with a malicious CSS payload in the margin-override settings and delivers it via social engineering or plants it in a shared/writable settings location.

AML.T0011.000

Import / auto-apply

Victim imports the file via the Settings Editor's Import button, or JupyterLab auto-applies it from a shared settings path.

AML.T0011

Code execution in frontend

Unsanitized override values are injected into style content, executing attacker script inside the victim's JupyterLab session.

AML.T0050

Kernel and data compromise

The executed code abuses the victim's authenticated session to call the notebook server API, read/modify notebooks and files, and run arbitrary code on the connected kernel.

AML.T0037

How severe is it?

CVSS 3.1

N/A

EPSS

0.7%

chance of exploitation in 30 days

Higher than 55% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade to JupyterLab 4.5.10 (4.x branch) or 4.6.2 immediately — both are patched. If immediate upgrade isn't possible, restrict the Settings Editor's Import feature via deployment configuration or extension policy where feasible, and lock down write permissions on any shared settings/config paths in JupyterHub or multi-tenant deployments so untrusted users can't plant an overrides.json. Advise users never to import a settings/overrides file received from an untrusted source, even if framed as a 'team layout' or 'theme preset.' For detection, audit JupyterHub shared volumes and user home directories for unexpected overrides.json files or recent writes to Jupyter settings paths, and review notebook server access logs for anomalous API calls following a settings-import event.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionSocial EngineeringFrameworkAML.T0011- User Execution AML.T0011.000- Unsafe AI Artifacts AML.T0050- Command and Scripting Interpreter

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.3-AI system security

NIST AI RMF

MANAGE-4.1-Risk monitoring and response for deployed AI systems

Frequently Asked Questions

What is CVE-2026-73417?

JupyterLab's Settings Editor lets users import an overrides.json file to customize the interface, but two margin-override fields aren't sanitized before being inserted into style content — a crafted file executes arbitrary code instead of just changing layout, and that code runs with the victim's full access to notebooks, files, and the connected kernel. This matters most for organizations running JupyterHub or other shared Jupyter deployments, where an attacker who can plant a file in a shared settings location doesn't need the victim to click anything at all. The immediate exploitation risk is low — EPSS sits at 0.55% (roughly median, top 56th percentile), the CVE isn't in CISA's KEV catalog, CISA's own SSVC decision is TRACK (lowest priority), and there's no public PoC or Nuclei template yet — but the impact ceiling is high given code execution reaches the kernel where credentials, training data, and model artifacts often live. Patch to JupyterLab 4.5.10 or 4.6.2 now; if you can't patch immediately, lock down write access to shared settings paths in multi-tenant deployments and tell users not to import overrides.json files from untrusted sources.

Is CVE-2026-73417 actively exploited?

No confirmed active exploitation of CVE-2026-73417 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-73417?

Upgrade to JupyterLab 4.5.10 (4.x branch) or 4.6.2 immediately — both are patched. If immediate upgrade isn't possible, restrict the Settings Editor's Import feature via deployment configuration or extension policy where feasible, and lock down write permissions on any shared settings/config paths in JupyterHub or multi-tenant deployments so untrusted users can't plant an overrides.json. Advise users never to import a settings/overrides file received from an untrusted source, even if framed as a 'team layout' or 'theme preset.' For detection, audit JupyterHub shared volumes and user home directories for unexpected overrides.json files or recent writes to Jupyter settings paths, and review notebook server access logs for anomalous API calls following a settings-import event.

What systems are affected by CVE-2026-73417?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model development environments, multi-tenant research platforms (JupyterHub).

What is the CVSS score for CVE-2026-73417?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel development environmentsmulti-tenant research platforms (JupyterHub)

MITRE ATLAS Techniques

AML.T0011User Execution

AML.T0011.000Unsafe AI Artifacts

AML.T0050Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.3

NIST AI RMF: MANAGE-4.1

What are the technical details?

Original Advisory

jupyterlab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From 3.3.0 until 4.5.10 and 4.6.2, JupyterLab allows notebook settings to be shared and applied through an overrides.json file using the Import button in the Settings Editor. In packages/notebook-extension/schema/tracker.json and packages/notebook-extension/src/index.ts, the sideBySideLeftMarginOverride and sideBySideRightMarginOverride settings are not properly validated before being inserted into style content, allowing a crafted settings file to contain instructions that execute as code instead of only changing display preferences. A user can import the malicious file, or an attacker with access to a shared settings location can plant an overrides.json that is applied automatically. The embedded code runs with the affected user's access and can read or modify notebooks and files and run code through the notebook server, including on a connected kernel. This issue is fixed in versions 4.5.10 and 4.6.2.

Exploitation Scenario

In a JupyterHub multi-tenant research environment, an attacker with access to a shared settings location (a shared network drive, a compromised low-privilege account, or a poisoned dotfile in a shared base image) plants a malicious overrides.json containing crafted sideBySideLeftMarginOverride/sideBySideRightMarginOverride values. When the victim's JupyterLab instance loads the settings — either auto-applied from the shared path, or manually imported after a phishing lure disguised as a 'team layout preset' — the unsanitized values are injected into style content, executing attacker script inside the victim's JupyterLab session. From there the code abuses the victim's authenticated session to call the notebook server's REST API, reading and modifying notebooks and files, and running arbitrary code on the connected kernel — reaching any cloud credentials, training data, or model artifacts accessible to that kernel.

Weaknesses (CWE)

CWE-116Improper Encoding or Escaping of OutputPrimary CWE-79Improper Neutralization of Input During Web Page GenerationPrimary CWE-116Improper Encoding or Escaping of Output CWE-79Improper Neutralization of Input During Web Page Generation

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.