Phishing Redirect Flaw in Jupyter Server CVE-2025-61669: Researcher Logins In The Crosshairs

The web-based programming environment Jupyter Server, used by researchers, data scientists, and students worldwide, has a flaw that turns its login page into a launchpad for phishing attacks. CVE-2025-61669 was reported by Noriaki Iwasaki of the Japanese security firm Cyber Defense Institute and published domestically via JPCERT/CC as JVN#01719116 on May 28, 2026.

The issue lives in the validation of the next query parameter used to send users back after they log in. Crafted URLs like /login?next=///example.com trick the server into bouncing the visitor to any external site after authentication. CVSS scores are 6.1 (v3.1) and 6.3 (v4.0) — both rated medium. The attack vector is network-based, requires no authentication, and only needs the victim to click a link. The targets are exactly the people whose accounts unlock the most: researchers holding sensitive datasets, models, and corporate credentials.

All Jupyter Server versions 2.17.0 and earlier are affected; the fix lands in 2.18.0. Because JupyterLab and Jupyter Notebook 7 run Jupyter Server under the hood, both inherit the same flaw. Multi-user JupyterHub deployments are no exception.

What Jupyter Server actually is

Jupyter Server is the web backend that powers the "notebook" interface where users write Python or R code in the browser and capture results inline. What people interact with directly is usually JupyterLab or Jupyter Notebook 7. Behind those frontends, Jupyter Server exposes the REST endpoints for file listing, kernel execution, and terminal access.

As the official docs note, most users never install Jupyter Server directly; it is pulled in as a dependency of JupyterLab or Notebook. Real-world deployments include:

• University courses for machine learning, statistics, and data science labs
• Corporate data teams running an in-house alternative to Google Colab
• Research labs with JupyterHub on top of shared GPU servers
• Managed services such as AWS SageMaker, Azure ML, and Google Vertex AI
• Personal Stable Diffusion / LLM experiment environments on home GPU rigs

Modern releases including Notebook v7.5.6 (April 2026) always call into Jupyter Server. A simple pip install jupyterlab or pip install notebook almost certainly pulls in a vulnerable Jupyter Server today.

Inside CVE-2025-61669

The root cause lives in LoginFormHandler._redirect_safe() in jupyter_server/auth/login.py. The intended design was a two-step check: allow only paths under the server's own base URL, or allow full URLs that pass the CORS origin check. NVD classifies it as CWE-601 (URL Redirection to Untrusted Site).

The PoC from GHSA-qh7q-6qm3-653w collapses to a single URL.

http://localhost:8888/login?next=///google.com

Visiting that URL and logging in sends the user to Google instead of back to the local server. Replace google.com with any attacker-controlled host and the redirect lands the victim on a fake login page.

Why does ///example.com get through? Browsers interpret //example.com as "same scheme as the current page, host example.com" (a protocol-relative URL), and the same logic extends to ///example.com. The server's validation, however, sees an empty scheme and empty netloc and decides "this must be a local path" — letting the redirect through. It is the textbook CWE-601 bypass.

Why a "mere redirect" makes phishing convincing

An open redirect (an attacker-controlled bounce to any URL) does not steal data by itself. OWASP still warns about it because it is the missing piece that makes a phishing email look legitimate.

A realistic lab / corporate JupyterHub scenario looks like this:

1. An attacker hosts a look-alike Jupyter login page at, say, phish.example
2. They send an email saying "the server was rebooted, please log in again" with a URL that starts with the real domain: https://jupyter.lab.univ.ac.jp/login?next=///phish.example
3. The recipient sees jupyter.lab.univ.ac.jp at the start of the URL and clicks
4. They land on the real Jupyter Server, log in, and get redirected to ///phish.example — the look-alike site
5. The look-alike says "your session expired, please re-enter your password" and harvests the credentials

The reason this works is that the first hostname the user sees is genuinely the lab's or company's. Mail-client link previews and browser address bars both display the real domain initially. In JupyterHub deployments protected by SAML or OAuth, harvested credentials translate directly into a foothold on the university or corporate identity provider.

For an attacker after research data or models, Jupyter credentials are a near-direct path. In SageMaker / Azure ML / Vertex AI environments, the linked IAM role can extend the blast radius far beyond a single notebook server.

Why JupyterLab and Notebook 7 inherit this

The second uncomfortable part of this CVE: users who never knowingly installed Jupyter Server are still exposed. JupyterLab and Jupyter Notebook 7 (the "successor to Classic Notebook") both call Jupyter Server internally. As this notebook dependency issue documents, Notebook 7.1+ requires jupyter_server.

The exposure matrix:

The entry point for remediation is bumping jupyter_server to 2.18.0+ via pip install -U jupyter_server or conda update jupyter_server, then restarting JupyterLab or Notebook. Cross-check the version against the latest PyPI release.

Watch out for Anaconda distributions or internal package mirrors that may lag. Run jupyter --version, check the jupyter_server line, and upgrade it individually if it is below 2.18.0.

Reported by Japan's Cyber Defense Institute

The reporter is Noriaki Iwasaki of the Tokyo-based independent security firm Cyber Defense Institute. The company specializes in penetration testing, forensics, and malware analysis, and has a track record of reporting vulnerabilities in domestic and overseas OSS through JPCERT/CC, including in EC-CUBE.

The GHSA credits also list Jupyter core maintainers Yann-P and Carreau (Matthias Bussonnier, well known as a long-time IPython/Jupyter maintainer) as coordinators, with dlqqq (David L. Qiu, Jupyter AI lead) authoring the fix. The flow — Japanese researcher reports, Jupyter core coordinates, fix ships in 2.18.0 — is a clean example of coordinated vulnerability disclosure.

The JVN domestic publication is May 28, 2026. GitHub's advisory went public on May 5, 2026, putting the JVN notice roughly three weeks behind. That gap is typical: many Japanese institutions do not track English-language security feeds directly, and JVN's domestic publication is what triggers downstream awareness inside national research institutes and SIers.

What researchers and operators should do now

Phishing is often framed as a "did the human get tricked?" problem, but whether an attacker can spoof your domain is something the technical side can decisively eliminate. For Jupyter Server operators and individual users alike, the short-term actions are:

• Upgrade jupyter_server to 2.18.0 or later
• For JupyterHub deployments, also update jupyter_server in the per-user (singleuser) images and conda environments spawners produce
• If you depend on SageMaker / Vertex AI / Azure ML managed notebooks, watch your cloud vendor's security feed for patched images and scheduled restarts
• Brief your lab or organization: a Jupyter login URL containing ?next= should not be clicked
• If a reverse proxy fronts your Jupyter Server, restrict /login access to internal networks as defense in depth

As a longer-term posture, combining a routine review of known-exploited vulnerabilities (see our CISA KEV dashboard) with automated dependency monitoring (our OSS supply chain scanner overview is a useful starting point) is the shortest path to catching this kind of "quietly bundled OSS" flaw early. Dependencies you never knowingly installed — like Jupyter Server — are exactly where automated scanning earns its keep.

Takeaway

CVE-2025-61669 is a CVSS 6.1 "medium" on paper, but the target is Jupyter Server — quietly running under the AI and data-science work of researchers worldwide — and the flaw automatically extends to JupyterLab and Notebook 7. The credentials being phished are exactly those of research and university accounts. Early patching is the realistic answer for both operators and end users.

It is also worth noting that Japanese researchers are systematically catching these "infrastructure-OSS" flaws, coordinating with Jupyter core, and making sure they reach JVN. That work is itself a meaningful contribution from the domestic security community. Before closing this tab, run pip list; if your jupyter_server still says 2.17.0 or earlier, this is the moment to upgrade.

References

• ▸ JVN#01719116 — Open redirect vulnerability in Jupyter Server (JPCERT/CC, May 28 2026)
• ▸ GitHub Security Advisory — GHSA-qh7q-6qm3-653w (jupyter-server, May 5 2026)
• ▸ NVD — CVE-2025-61669
• ▸ jupyter_server/auth/login.py (patched code)
• ▸ jupyter-server — PyPI
• ▸ Cyber Defense Institute, Inc. (reporter affiliation)
• ▸ OWASP — Open Redirect
• ▸ CWE-601: URL Redirection to Untrusted Site