CVE-2025-61669: Jupyter Open redirect enables

Q: Is CVE-2025-61669 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2025-61669, increasing the risk of exploitation.

Q: How to fix CVE-2025-61669?

1. Upgrade jupyter-server to 2.18.0 or later — this is the sole available fix; no workaround exists. 2. Audit all Jupyter deployments for public internet exposure; restrict access behind VPN or allowlisted IP ranges. 3. Review web server and application logs for login requests containing `?next=` parameters pointing to external URLs. 4. Implement ingress/egress firewall rules that flag or block login redirect traffic to unexpected external domains. 5. Alert ML engineering and data science teams not to click Jupyter login links received via email, Slack, or messaging platforms. 6. For JupyterHub, validate that the hub's reverse proxy enforces redirect target allowlisting at the infrastructure layer as a defense-in-depth measure.

Q: What systems are affected by CVE-2025-61669?

This vulnerability affects the following AI/ML architecture patterns: ML development environments, Training pipelines, Data science workstations, Collaborative ML platforms, JupyterHub deployments.

Q: What is the CVSS score for CVE-2025-61669?

No CVSS score has been assigned yet.

CISO Take

Jupyter Server 2.17.0 and below contains an open redirect flaw in its login endpoint that allows an attacker to craft a URL silently bouncing users to any external domain — enabling convincing credential phishing with zero technical barriers beyond social engineering. With 1,862 downstream dependents and Jupyter deeply embedded in AI/ML development workflows globally, the blast radius across data science and ML engineering teams is substantial, particularly for organizations running public-facing notebook environments. The raw exploitation probability is low (EPSS 0.013%) and no public exploits or active KEV listing exist, but the trivial mechanics — appending `?next=///malicious.com` to a login link — mean any threat actor can weaponize this without AI or security expertise. Upgrade to Jupyter Server 2.18+ immediately; no workaround exists.

Sources: NVD GitHub Advisory EPSS ATLAS OpenSSF

What is the risk?

MEDIUM risk overall, elevated for organizations with public-facing Jupyter deployments. Exploitation is trivial — no authentication, no special tooling, just a crafted URL — but requires social engineering delivery, which introduces a human-interaction dependency. The absence of CISA KEV listing, public exploits, and Nuclei templates reduces urgency. However, the OpenSSF Scorecard of 4.8/10 and 9 prior CVEs in the same package signal systemic security debt. Enterprise environments where Jupyter hosts notebooks containing API keys, training data pipelines, and proprietary model code face disproportionate credential-theft risk if phishing succeeds.

How does the attack unfold?

Target Identification

Adversary identifies public-facing Jupyter Server instances at victim organization through passive DNS enumeration, search engine dorking, or LinkedIn recon of data science teams.

AML.T0006

Malicious URL Crafting

Adversary registers a lookalike domain and constructs a login URL with `?next=///` redirect to an attacker-controlled phishing page cloning the legitimate Jupyter interface.

AML.T0049

Phishing Delivery

Crafted URL is distributed to ML engineers or data scientists via spearphishing email or messaging platform, appearing as a legitimate session expiration notification.

AML.T0052

Credential Harvest & AI Asset Access

Victim enters credentials on the spoofed page; attacker uses harvested credentials to access the legitimate Jupyter environment and exfiltrate notebooks, API keys, training data paths, and model artifacts.

AML.T0012

Target Identification

Adversary identifies public-facing Jupyter Server instances at victim organization through passive DNS enumeration, search engine dorking, or LinkedIn recon of data science teams.

AML.T0006

Malicious URL Crafting

Adversary registers a lookalike domain and constructs a login URL with `?next=///` redirect to an attacker-controlled phishing page cloning the legitimate Jupyter interface.

AML.T0049

Phishing Delivery

Crafted URL is distributed to ML engineers or data scientists via spearphishing email or messaging platform, appearing as a legitimate session expiration notification.

AML.T0052

Credential Harvest & AI Asset Access

Victim enters credentials on the spoofed page; attacker uses harvested credentials to access the legitimate Jupyter environment and exfiltrate notebooks, API keys, training data paths, and model artifacts.

AML.T0012

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	—	No patch
13.2K OpenSSF 5.8 1.9K dependents Pushed 4d ago 79% patched ~9d to patch Full package profile →
Jupyter	pip	<= 2.17.0	`2.18.0`
13.2K OpenSSF 5.8 1.9K dependents Pushed 4d ago 79% patched ~9d to patch Full package profile →
Jupyter Notebook	pip	—	No patch
13.2K OpenSSF 5.8 3.0K dependents Pushed 4d ago 60% patched ~340d to patch Full package profile →

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 18% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

6 steps

Upgrade jupyter-server to 2.18.0 or later — this is the sole available fix; no workaround exists.
Audit all Jupyter deployments for public internet exposure; restrict access behind VPN or allowlisted IP ranges.
Review web server and application logs for login requests containing ?next= parameters pointing to external URLs.
Implement ingress/egress firewall rules that flag or block login redirect traffic to unexpected external domains.
Alert ML engineering and data science teams not to click Jupyter login links received via email, Slack, or messaging platforms.
For JupyterHub, validate that the hub's reverse proxy enforces redirect target allowlisting at the infrastructure layer as a defense-in-depth measure.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

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

How is it classified?

Social Engineering Auth Bypass Framework API AML.T0011.003 - Malicious Link AML.T0012 - Valid Accounts AML.T0025 - Exfiltration via Cyber Means AML.T0049 - Exploit Public-Facing Application AML.T0052 - Phishing

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk Management System

ISO 42001

A.9.4 - AI System Security

NIST AI RMF

GOVERN-1.2 - Accountability MANAGE-2.4 - Risk Treatment

OWASP LLM Top 10

LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-61669?

Jupyter Server 2.17.0 and below contains an open redirect flaw in its login endpoint that allows an attacker to craft a URL silently bouncing users to any external domain — enabling convincing credential phishing with zero technical barriers beyond social engineering. With 1,862 downstream dependents and Jupyter deeply embedded in AI/ML development workflows globally, the blast radius across data science and ML engineering teams is substantial, particularly for organizations running public-facing notebook environments. The raw exploitation probability is low (EPSS 0.013%) and no public exploits or active KEV listing exist, but the trivial mechanics — appending `?next=///malicious.com` to a login link — mean any threat actor can weaponize this without AI or security expertise. Upgrade to Jupyter Server 2.18+ immediately; no workaround exists.

Is CVE-2025-61669 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2025-61669, increasing the risk of exploitation.

How to fix CVE-2025-61669?

1. Upgrade jupyter-server to 2.18.0 or later — this is the sole available fix; no workaround exists. 2. Audit all Jupyter deployments for public internet exposure; restrict access behind VPN or allowlisted IP ranges. 3. Review web server and application logs for login requests containing `?next=` parameters pointing to external URLs. 4. Implement ingress/egress firewall rules that flag or block login redirect traffic to unexpected external domains. 5. Alert ML engineering and data science teams not to click Jupyter login links received via email, Slack, or messaging platforms. 6. For JupyterHub, validate that the hub's reverse proxy enforces redirect target allowlisting at the infrastructure layer as a defense-in-depth measure.

What systems are affected by CVE-2025-61669?

This vulnerability affects the following AI/ML architecture patterns: ML development environments, Training pipelines, Data science workstations, Collaborative ML platforms, JupyterHub deployments.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

ML development environmentsTraining pipelinesData science workstationsCollaborative ML platformsJupyterHub deployments

MITRE ATLAS Techniques

AML.T0011.003 Malicious Link

AML.T0012 Valid Accounts

AML.T0025 Exfiltration via Cyber Means

AML.T0049 Exploit Public-Facing Application

AML.T0052 Phishing

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.9.4

NIST AI RMF: GOVERN-1.2, MANAGE-2.4

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

### Summary The `?next=...` URL query parameter has an open redirection vulnerability. In `jupyter_server<=2.17.0`, this URL query parameter allows redirection to arbitrary external domains, which can be exploited to facilitate phishing attacks on server users. ### Details The vulnerability is caused by insufficient validation in the `LoginFormHandler._redirect_safe()` method. - Source code reference: https://github.com/jupyter-server/jupyter_server/blob/987ebdd5e188cdc49751b01a0d6782d686492a53/jupyter_server/auth/login.py#L33-L76 This vulnerability was originally reported by Noriaki Iwasaki. All discovery credit goes to them. ### PoC 1. Navigate to `http://localhost:8888/login?next=///google.com` 2. Observe that the user is redirected to `google.com` despite it being an external domain. The external domain passed in the `?next` parameter may be replaced with a malicious lookalike to facilitate phishing attacks. Jupyter Server deployments served on a public domain are especially vulnerable, as `prod.company.com` may be redirected to a look-alike URL such as `prod.company.dev`. ### Impact This vulnerability affects all users, especially enterprise users who work with sensitive/confidential data. ### Patches Jupyter Server 2.18+ ### Workaround None.

Exploitation Scenario

An adversary targeting an AI engineering team identifies a public-facing Jupyter Server instance at `notebooks.company.com` via passive DNS or LinkedIn recon. They register `notebooks.company.dev`, clone the Jupyter login UI, and craft the URL `https://notebooks.company.com/login?next=///notebooks.company.dev/login`. This URL is sent via a spearphishing email impersonating IT operations — 'Your Jupyter session expired, click to re-authenticate.' The data scientist clicks, is transparently redirected to the lookalike site, enters credentials, and is bounced back to the real Jupyter with an error. The attacker now holds valid credentials to a notebook environment containing OpenAI API keys, S3 training data paths, and unreleased model checkpoints.

Weaknesses (CWE)

CWE-601 URL Redirection to Untrusted Site ('Open Redirect') Primary

CWE-601 — URL Redirection to Untrusted Site ('Open Redirect'): The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Source: MITRE CWE corpus.