CVE-2018-21030: Jupyter Notebook XSS

CISO Take

Jupyter Notebook instances lacking a CSP header allow XSS attacks via crafted SVG files, enabling session hijacking and credential theft in shared ML environments. In data science teams where Jupyter is deployed on internal networks — often without authentication — this is a realistic lateral movement vector. Upgrade to 5.5.0+ immediately and ensure all Jupyter deployments sit behind authenticated reverse proxies.

What is the risk?

CVSS 5.3 understates real-world risk in AI/ML contexts. The attack vector requires no privileges and no user interaction (AV:N/AC:L/PR:N/UI:N), and Jupyter is routinely deployed as a shared service on internal networks. Low EPSS (0.37%) suggests limited active exploitation in the wild, but the technique is trivial — any attacker with file upload access can compromise all active sessions on the server. Shared notebook environments used by multiple data scientists amplify blast radius significantly.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter Notebook	pip	< 5.5.0rc1	`5.5.0rc1`
13.2K OpenSSF 5.8 3.0K dependents Pushed 4d ago 60% patched ~340d to patch Full package profile →

Do you use Jupyter Notebook? You're affected.

How severe is it?

CVSS 3.1

5.3 / 10

EPSS

1.4%

chance of exploitation in 30 days

Higher than 70% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C None

I Low

A None

What should I do?

6 steps

Upgrade to notebook >= 5.5.0 (applies CSP header treating served files as separate origin).
If upgrade is blocked, enforce authenticated reverse proxy (nginx + auth_request) in front of all Jupyter instances.
Disable serving of untrusted file types via Jupyter's content manager configuration.
Enforce network segmentation: Jupyter servers must not be internet-accessible or accessible from untrusted VLANs.
Audit asset inventory for exposed Jupyter instances using internal port scans (default port 8888).
Detection: alert on SVG file creation/upload events on notebook servers and monitor for unusual outbound requests originating from browser sessions on Jupyter hosts.

How is it classified?

Code Execution Data Leakage Framework AML.T0025 - Exfiltration via Cyber Means AML.T0036 - Data from Information Repositories AML.T0049 - Exploit Public-Facing Application

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 - Information security in AI system development

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain oversight of AI system risks

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2018-21030?

Jupyter Notebook instances lacking a CSP header allow XSS attacks via crafted SVG files, enabling session hijacking and credential theft in shared ML environments. In data science teams where Jupyter is deployed on internal networks — often without authentication — this is a realistic lateral movement vector. Upgrade to 5.5.0+ immediately and ensure all Jupyter deployments sit behind authenticated reverse proxies.

Is CVE-2018-21030 actively exploited?

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

How to fix CVE-2018-21030?

1. Upgrade to notebook >= 5.5.0 (applies CSP header treating served files as separate origin). 2. If upgrade is blocked, enforce authenticated reverse proxy (nginx + auth_request) in front of all Jupyter instances. 3. Disable serving of untrusted file types via Jupyter's content manager configuration. 4. Enforce network segmentation: Jupyter servers must not be internet-accessible or accessible from untrusted VLANs. 5. Audit asset inventory for exposed Jupyter instances using internal port scans (default port 8888). 6. Detection: alert on SVG file creation/upload events on notebook servers and monitor for unusual outbound requests originating from browser sessions on Jupyter hosts.

What systems are affected by CVE-2018-21030?

This vulnerability affects the following AI/ML architecture patterns: data science notebooks, model development environments, training pipelines, experiment tracking infrastructure.

What is the CVSS score for CVE-2018-21030?

CVE-2018-21030 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 1.44%.

What is the AI security impact?

Affected AI Architectures

data science notebooksmodel development environmentstraining pipelinesexperiment tracking infrastructure

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0036 Data from Information Repositories

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.3

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

Jupyter Notebook before 5.5.0 does not use a CSP header to treat served files as belonging to a separate origin. Thus, for example, an XSS payload can be placed in an SVG document.

Exploitation Scenario

An attacker with any write access to a shared Jupyter environment — compromised data scientist account, insider, or misconfigured S3 bucket mounted as a notebook directory — uploads a malicious SVG containing JavaScript. When a colleague opens or previews the file via the Jupyter file browser, the script executes in the notebook server's origin, sharing context with all authenticated sessions. The attacker harvests session cookies, exfiltrates .ipynb files containing hardcoded cloud credentials and model code, and pivots to connected services (MLflow, Weights & Biases, S3, GCP) using stolen tokens embedded in notebooks.

Weaknesses (CWE)

CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Primary

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

[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 [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
[Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.