CVE-2025-59842: JupyterLab: missing noopener enables reverse tabnabbing

GHSA-vvfj-2jqx-52jm LOW
Published September 26, 2025
CISO Take

No immediate action required for standard deployments — default JupyterLab installations using official mathjax/katex extensions are unaffected. Upgrade to JupyterLab 4.4.8 as routine patch hygiene. If your data science teams run custom third-party LaTeX rendering extensions, audit those extensions for target=_blank usage before dismissing.

What is the risk?

Negligible real-world risk. EPSS of 0.00031 reflects near-zero exploitation probability. The attack is theoretical: it requires a non-existent precondition — a third-party LaTeX extension that adds target=_blank, of which none are known at time of disclosure. The patch is a defense-in-depth improvement enforcing secure link rendering defaults. Not in CISA KEV. Not exploitable in default configurations.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Jupyter pip <= 4.4.7 4.4.8
13.2K OpenSSF 5.8 1.9K dependents Pushed 4d ago 79% patched ~9d to patch Full package profile →

Do you use Jupyter? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.2%
chance of exploitation in 30 days
Higher than 11% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

5 steps
  1. Upgrade jupyterlab to 4.4.8 (pip install --upgrade jupyterlab).

  2. Audit any non-official LaTeX typesetter extensions in your JupyterLab deployment for target=_blank in link rendering.

  3. Enforce extension allowlisting policies — only permit vetted extensions in production data science environments.

  4. No workarounds needed for default installations.

  5. Detection: review installed JupyterLab extensions (jupyter labextension list) for unrecognized LaTeX rendering plugins.

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?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
8.4 - AI system security
NIST AI RMF
GOVERN 6.1 - Policies and procedures for third-party AI risk
OWASP LLM Top 10
LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2025-59842?

No immediate action required for standard deployments — default JupyterLab installations using official mathjax/katex extensions are unaffected. Upgrade to JupyterLab 4.4.8 as routine patch hygiene. If your data science teams run custom third-party LaTeX rendering extensions, audit those extensions for target=_blank usage before dismissing.

Is CVE-2025-59842 actively exploited?

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

How to fix CVE-2025-59842?

1. Upgrade jupyterlab to 4.4.8 (pip install --upgrade jupyterlab). 2. Audit any non-official LaTeX typesetter extensions in your JupyterLab deployment for target=_blank in link rendering. 3. Enforce extension allowlisting policies — only permit vetted extensions in production data science environments. 4. No workarounds needed for default installations. 5. Detection: review installed JupyterLab extensions (jupyter labextension list) for unrecognized LaTeX rendering plugins.

What systems are affected by CVE-2025-59842?

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

What is the CVSS score for CVE-2025-59842?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

data science workbenchestraining pipelinesmodel development environments

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0011.001 Malicious Package
AML.T0011.003 Malicious Link

Compliance Controls Affected

ISO 42001: 8.4
NIST AI RMF: GOVERN 6.1
OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

Links generated with LaTeX typesetters in Markdown files and Markdown cells in JupyterLab and Jupyter Notebook did not include the `noopener` attribute. This is deemed to have no impact on the default installations. Theoretically users of third-party LaTeX-rendering extensions could find themselves vulnerable to reverse tabnabbing attacks if: - links generated by those extensions included `target=_blank` (no such extensions are known at time of writing) and - they were to click on a link generated in LaTeX (typically visibly different from other links). For consistency with handling on other links, new versions of JupyterLab will enforce `noopener` and `target=_blank` on all links generated by typesetters. The former will harden the resilience of JupyterLab to extensions with lack of secure defaults in link rendering, and the latter will improve user experience by preventing accidental state loss when clicking on links rendered by LaTeX typesetters. ### Impact Since the official LaTeX typesetter extensions for JupyterLab: `jupyterlab-mathjax` (default), `jupyterlab-mathjax2` and `jupyterlab-katex` do not include the `target=_blank`, there is no impact for JupyterLab users. ### Patches JupyterLab 4.4.8 ### Workarounds No workarounds are necessary. ### References None

Exploitation Scenario

An adversary publishes a malicious JupyterLab LaTeX rendering extension to PyPI or npm that injects target=_blank into rendered links. A data scientist installs it to enable a specific LaTeX rendering feature. When they open a notebook containing LaTeX-rendered hyperlinks and click one, window.opener remains accessible to the destination page. The adversary's server detects the window.opener reference and silently redirects the original JupyterLab tab to a convincing fake login page, harvesting the researcher's credentials — which may include API keys for LLM services, model registries, or cloud ML platforms.

Weaknesses (CWE)

CWE-1022 — Use of Web Link to Untrusted Target with window.opener Access: The web application produces links to untrusted external sites outside of its sphere of control, but it does not properly prevent the external site from modifying security-critical properties of the window.opener object, such as the location property.

  • [Architecture and Design] Specify in the design that any linked external document must not be granted access to the location object of the calling page.
  • [Implementation] When creating a link to an external document using the ‹a> tag with a defined target, for example "_blank" or a named frame, provide the rel attribute with a value "noopener noreferrer". If opening the external document in a new window via javascript, then reset the opener by setting it equal to null.

Source: MITRE CWE corpus.

Timeline

Published
September 26, 2025
Last Modified
September 26, 2025
First Seen
March 24, 2026

Related Vulnerabilities