CVE-2026-67338: stored XSS — MEDIUM

CISO Take

JupyterLab's Extension Manager fails to validate URI protocols in package metadata, letting an attacker publish a PyPI package with a javascript: URL that executes arbitrary JavaScript in the JupyterLab origin the moment a user clicks the extension's name. This matters because JupyterLab notebooks are the default workbench for data scientists and ML engineers, and code running in the JupyterLab origin can potentially reach the session's auth token and REST API, turning a single click into server-level compromise. The absolute exploitation probability is low (EPSS 0.175%), there's no public PoC or Nuclei template, it's not in CISA KEV, and CISA's own SSVC decision is TRACK — so this is not an urgent fire drill, though its EPSS percentile still places it above the median CVE in relative likelihood. Upgrade to JupyterLab 4.5.9 or later; until then, treat unfamiliar PyPI extensions in the Extension Manager as untrusted and avoid clicking extension names from unverified publishers, and consider restricting outbound Extension Manager searches to vetted internal package sources.

Sources: NVD GitHub Advisory EPSS vulncheck.com ATLAS

What is the risk?

Medium severity (CVSS 6.1, AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N). Network-reachable and low complexity, but blocked by a mandatory user-interaction gate (clicking the malicious extension name) and yields only low confidentiality/integrity impact per the vector — no availability impact. Scope is Changed, meaning the XSS can affect resources beyond the vulnerable component (e.g., the browser session/origin), which is the main reason this isn't rated low. No active exploitation, no KEV listing, no public exploit code or scanner template, and EPSS absolute probability is under 0.2%. Overall: real but contained risk, gated by social engineering and requiring a user to actively browse and click on a specific untrusted package.

How does the attack unfold?

Malicious Package Publication

Attacker publishes a PyPI package impersonating a legitimate JupyterLab extension, embedding a javascript: URI in the project metadata URL field.

AML.T0011.001

Discovery via Extension Manager

A JupyterLab user browses or searches the Extension Manager and the malicious package appears in the results.

User Click Triggers XSS

The user clicks the extension's name, causing the unsanitized javascript: URL to execute arbitrary JavaScript in the JupyterLab origin.

AML.T0011

Session Compromise / Pivot

The injected script attempts to access session tokens or manipulate the JupyterLab UI, potentially enabling further access to the notebook server's API.

Malicious Package Publication

Attacker publishes a PyPI package impersonating a legitimate JupyterLab extension, embedding a javascript: URI in the project metadata URL field.

AML.T0011.001

Discovery via Extension Manager

A JupyterLab user browses or searches the Extension Manager and the malicious package appears in the results.

User Click Triggers XSS

The user clicks the extension's name, causing the unsanitized javascript: URL to execute arbitrary JavaScript in the JupyterLab origin.

AML.T0011

Session Compromise / Pivot

The injected script attempts to access session tokens or manipulate the JupyterLab UI, potentially enabling further access to the notebook server's API.

How severe is it?

CVSS 3.1

6.1 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 7% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Changed

C Low

I Low

A None

What should I do?

1 step

Patch: upgrade JupyterLab to 4.5.9 or later, which fixes URI protocol validation in Extension Manager package metadata rendering. Workaround if patching is delayed: disable or restrict the Extension Manager for non-admin users, or block installation of extensions from unvetted PyPI packages via an internal allowlist. User awareness: train users not to click extension names/links from unfamiliar or newly-published packages in the Extension Manager UI. Detection: monitor JupyterLab server logs for anomalous extension search/install activity and review browser-side CSP violation reports if CSP is enforced; audit recently installed extensions for suspicious metadata URLs (javascript: scheme) as an IOC.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Supply Chain Code Execution Social Engineering Plugin AML.T0010.001 - AI Software AML.T0011 - User Execution AML.T0011.001 - Malicious Package

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.3 - Third-party and supplier relationships for AI system components

NIST AI RMF

GOVERN-6.1 - Third-party AI/ML component and supply chain risk management

Frequently Asked Questions

What is CVE-2026-67338?

JupyterLab's Extension Manager fails to validate URI protocols in package metadata, letting an attacker publish a PyPI package with a javascript: URL that executes arbitrary JavaScript in the JupyterLab origin the moment a user clicks the extension's name. This matters because JupyterLab notebooks are the default workbench for data scientists and ML engineers, and code running in the JupyterLab origin can potentially reach the session's auth token and REST API, turning a single click into server-level compromise. The absolute exploitation probability is low (EPSS 0.175%), there's no public PoC or Nuclei template, it's not in CISA KEV, and CISA's own SSVC decision is TRACK — so this is not an urgent fire drill, though its EPSS percentile still places it above the median CVE in relative likelihood. Upgrade to JupyterLab 4.5.9 or later; until then, treat unfamiliar PyPI extensions in the Extension Manager as untrusted and avoid clicking extension names from unverified publishers, and consider restricting outbound Extension Manager searches to vetted internal package sources.

Is CVE-2026-67338 actively exploited?

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

How to fix CVE-2026-67338?

Patch: upgrade JupyterLab to 4.5.9 or later, which fixes URI protocol validation in Extension Manager package metadata rendering. Workaround if patching is delayed: disable or restrict the Extension Manager for non-admin users, or block installation of extensions from unvetted PyPI packages via an internal allowlist. User awareness: train users not to click extension names/links from unfamiliar or newly-published packages in the Extension Manager UI. Detection: monitor JupyterLab server logs for anomalous extension search/install activity and review browser-side CSP violation reports if CSP is enforced; audit recently installed extensions for suspicious metadata URLs (javascript: scheme) as an IOC.

What systems are affected by CVE-2026-67338?

This vulnerability affects the following AI/ML architecture patterns: notebook-based ML/data science development environments, training and experimentation pipelines (JupyterLab front-end), supply chain / package ecosystem (PyPI).

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

CVE-2026-67338 has a CVSS v3.1 base score of 6.1 (MEDIUM). The EPSS exploitation probability is 0.17%.

What is the AI security impact?

Affected AI Architectures

notebook-based ML/data science development environmentstraining and experimentation pipelines (JupyterLab front-end)supply chain / package ecosystem (PyPI)

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0011 User Execution

AML.T0011.001 Malicious Package

Compliance Controls Affected

ISO 42001: A.6.2.3

NIST AI RMF: GOVERN-6.1

What are the technical details?

Original Advisory

JupyterLab before 4.5.9 contains a stored cross-site scripting vulnerability in the Extension Manager that fails to validate URI protocols in package metadata URLs. Attackers can publish malicious PyPI packages with javascript: URLs in project metadata that execute arbitrary JavaScript in the JupyterLab origin when users click the extension name.

Exploitation Scenario

An attacker registers a PyPI package designed to look like a legitimate JupyterLab extension (e.g., mimicking a popular ML tooling name) and sets a javascript: URI in the project metadata URL field. The package is indexed and becomes visible via JupyterLab's Extension Manager search. A data scientist searching for new extensions browses the results and clicks the malicious package's name, triggering execution of the attacker's JavaScript within the JupyterLab origin. The script attempts to read session tokens or cookies from the JupyterLab origin and exfiltrate them to an attacker-controlled endpoint, or manipulates the DOM to trick the user into further unsafe actions — potentially escalating to abuse of the Jupyter server's REST/kernel API if a valid token is captured.

Weaknesses (CWE)

CWE-84 Improper Neutralization of Encoded URI Schemes in a Web Page Primary CWE-84 Improper Neutralization of Encoded URI Schemes in a Web Page

CWE-84 — Improper Neutralization of Encoded URI Schemes in a Web Page: The web application improperly neutralizes user-controlled input for executable script disguised with URI encodings.

[Implementation] Resolve all URIs to absolute or canonical representations before processing.
[Implementation] Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.

Source: MITRE CWE corpus.