Jupyter Blog - security

Jupyter Security Sprint March 31st

2026-03-20T19:47:00+00:00

This is a critical moment for open source software. AI enables new contributors in new ways, but maintainers are also faced with an unprecedented volume of contributions and security reports. This speed also puts pressure on maintainers and the processes that keep projects secure and reliable.

At the same time, there have been significant recent advances in tooling for:

dependency analysis
vulnerability scanning
supply chain security
automated security checks in CI pipelines

But many open source software projects still struggle to evaluate and integrate these tools into their workflows.

The Security Tooling Sprint

To help address this challenge, the Linux Foundation and the Berkeley Institute for Data Science (BIDS) are hosting the Security Tooling Sprint on March 31st. This sprint will bring together maintainers, security experts, and contributors to explore how security tooling can better support the secure development of Project Jupyter.

Participants will work to understand what tools exist, what problems they solve, and how they can be used in real projects.

What We Will Do

During the sprint, participants will work together to explore the current landscape of security tooling and apply it to real workflows.

Activities will include:

identifying common maintainer pain points
reviewing the modern security tooling ecosystem
experimenting with tools in real project environments
sharing results and ideas with the group

The event focuses on collaboration and hands-on exploration in order to derive actionable recommendations back as issues and pull requests.

Why This Matters for Jupyter

Project Jupyter is used by millions of people in research, education, and industry. Like many open source projects, it relies on a global community of maintainers and contributors volunteering their time, energy, and expertise.

Improving security practices helps protect users while reducing maintainer burden and strengthening trust in the ecosystem.

Join Us

If you are interested in open source security, developer tooling, or the future of the Jupyter ecosystem, we encourage you to participate.

Learn more and register here. We hope you will join us in Berkeley and help improve how to evolve how open source communities approach security.

European Commission Funds Jupyter Bug Bounty Program

2023-07-28T19:46:00+00:00

Three Jupyter Subprojects – Jupyter Server, JupyterLab, and JupyterHub –are participating in a bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.

Intigriti is a cybersecurity company that specializes in crowdsourced security services like bug bounty programs, hybrid penetration testing, and hosting live hacking events. The financial support covers bounties from €250 to €5,000 and is part of the European Commission’s Open Source Software Strategy 2020–2023, which:

Promotes the sharing and reuse of software solutions, knowledge and expertise, to deliver better European services that benefit society and lower costs to that society. The Commission commits to increasing its use of open source not only in practical areas such as IT, but also in areas where it can be strategic.

This is a great opportunity for Project Jupyter to reduce the number of potential vulnerabilities in critical Jupyter components and to evaluate our vulnerability handling processes.

Project Jupyter was selected for sponsorship at the end of 2022. After discussions involving several Jupyter Subprojects and other stakeholders, the three Jupyter software components were chosen for inclusion. Representatives from Jupyter Server, JupyterLab, and JupyterHub have committed to validating and responding to submissions for their area. Focusing on a limited number of key Jupyter components was a way to balance the benefits of identifying vulnerabilities against developer obligations to review vulnerability submissions. The Jupyter Security Subproject is contributing to this effort by drafting the bug bounty program details and being a liaison between Intigriti and the other Jupyter Subprojects.

Submissions are triaged by Intigriti, including reproducing potential vulnerabilities and assigning a severity. The triage process ensures that submissions fall within the scope (software components, versions, etc.) defined by the program. Vulnerability severity is based on Intigriti’s contextualized Common Vulnerability Scoring System (CVSS) and assigned a rating of low, medium, high, critical, or exceptional. The severity determines both the bounty and the response time for Project Jupyter to validate a submission. After a submission passes triage, it is sent to Project Jupyter for validation.

Project Jupyter appreciates the financial support from the European Commission and the help by Intigriti representatives to establish the program. Security researchers and others interested in the bug bounty program can view the details on the Intigriti website.

Requiring 2FA for Jupyter GitHub Organizations

2022-07-05T15:00:00+00:00

This requirement and the outlined plan was discussed and agreed upon at the Jupyter Governance meeting on Friday, July 1, 2022.

By October 1, 2022, Project Jupyter aims to require two-factor authentication (2FA) for all GitHub organizations hosting repositories for official Jupyter Subprojects.

Enabling 2FA is the single most important step Jupyter contributors can take to protect their GitHub accounts from bad actors. This benefits the entire Jupyter Community by reducing the chance for malicious code to be slipped into a repository.

Fortunately, most Jupyter GitHub organization members and external collaborators have 2FA enabled, at this time. This process will get us to 100% so we can enable the requirement as a GitHub org setting.

What’s the process?

GitHub Documentation on 2FA

We recommend that all GitHub users secure their account with 2FA, even if you don’t have an organizational role like admin or owner, or write permissions to a Jupyter repository.

Over the next month (by August 1, 2022) contributors to the Jupyter Security Subproject will reach out to owners of each Jupyter GitHub org with a list of their users without 2FA enabled. The list of users will be an intersection across the GitHub orgs so that users aren’t contacted multiple times, and org maintainers are asked to do double work.

From there, the org owners can decide how they want to work within their area of the Community. They may choose to contact the users or ask the Security Subproject to reach out to the users. Or, the users without 2FA may no longer need the access or role they were granted.

At end of August, 2022, we’ll review the list of the remaining accounts without 2FA. (Hopefully none!) If possible, we’ll begin enabling the requirement on our GitHub orgs. The Security Subproject will work with org owners on plans for contacting any remaining users.

At the end of September, 2022, users without 2FA enabled may lose explicit permissions or roles within Jupyter GitHub orgs. This will only impact access to private repositories, commit privileges, or having a role such as owner or admin. Read access to public repositories will remain the same, along with opening issues or pull requests. And once users enable 2FA on their account, any previous permissions or roles can be restored.

What GitHub orgs does this apply to?

All GitHub orgs hosting repositories for official Jupyter Subprojects.

Please don’t disable authentication in Jupyter servers

2022-04-05T09:50:00+00:00

We are aware of ransomware attacks specifically targeting Jupyter servers.

First off: we have no evidence of a vulnerability in Jupyter associated with the attack. The attacks appear to focus on Jupyter servers with authentication disabled. That’s what this post is about: please don’t do that!

Jupyter servers are authenticated with a random token by default, so you should be fine with the defaults. That default random token is regenerated on each server launch. If that random token is inconvenient for you (there are plenty of situations where this is the case), the answer is not to disable auth! More on that below.

We wrote about this before, but it bears repeating:

Jupyter exposes arbitrary code execution and a shell. If folks gain access, they can do anything you can do. You aren’t just protecting your notebooks, you are protecting your whole computer.
People can find your notebook server if it’s accessible on the Internet. If they locate your server and it has auth disabled, that’s game over, and appears to be what happened in the above ransomware event. Jupyter’s popular enough (yay) that folks are always looking (boo).
If the generated token pattern is inconvenient for how you work, you can set a persistent token or password in configuration instead of retrieving the generated token on each server launch. Save this token or password in your password manager for safe keeping, and accessing your server will be just as convenient as auth being disabled.

If you have an interactive prompt, you can run jupyter server password

$ jupyter server password
Enter password:🔐
Verify password:🔐
[JupyterPasswordApp] Wrote hashed password to ~/.jupyter/jupyter_server_config.json

which generates and stores config that looks like:

{
  "ServerApp": {
    "password": "argon2:$argon2id$v=19$m=10240,t=10,p=8$aFE/DuLj//6oGF2PHWy2DQ$eXHn6AbJe8Lryl4z9oGvMtZhX7iEdt41m+mhvyDvw88"
  }
}

This is a hashed, salted form of your password. We can’t get the password out of this, but we can use it to check if you typed it correctly on the login page. If an interactive prompt isn’t available to you (e.g. a cloud vm that starts the notebook server automatically), you can run this command on any machine, and copy the resulting config file to the destination machine as part of setup.

If it works better for you, you can also generate just the hashed password:

from jupyter_server.auth import passwd
hashed_password = passwd("my-great-passphrase") # just the "argon2:..."

and get that into your config files, as best suits your needs. For example, in ~/.jupyter/jupyter_server_config.py:

c.ServerApp.password = "argon2:..."

or the same config in ~/.jupyter/jupyter_server_config.json

{
  "ServerApp": {
    "password": "argon2:..."
  }
}

Read more details in our earlier post, and security documentation.

Please contact security@ipython.org if you have a vulnerability to report.

Trusted CI Cybersecurity Engagement with Jupyter

2021-09-15T18:09:00+00:00

Trusted CI is the US National Science Foundation Cybersecurity Center of Excellence, staffed by cybersecurity experts who have spent decades working with science and engineering communities and who have established track records in terms of usable, high-quality solutions suited to the needs of those communities. The team draws from best operational practices and includes leaders in the research and development of new methodologies and high-quality implementations. In addition to providing leadership, education, outreach, and training to raise the state of security practice across the sciences, Trusted CI undertakes one-on-one engagements with projects to address their cybersecurity challenges.

As a part of timely, broader efforts to make Project Jupyter more responsive and proactive to security, the new security sub-project this past summer has undertaken a one-on-one engagement with Trusted CI to run through the end of 2021. This Trusted CI engagement was originally motivated by an upcoming Jupyter Security Best Practices Workshop funded by NumFOCUS as part of the Community Workshop series. The workshop is tentatively scheduled to be held April 2022 at the Ohio Supercomputer Center.

The goals of the engagement between Project Jupyter and Trusted CI include the following tasks:

Review existing Jupyter deployment documentation related to security, identify gaps, and create recommendations for improvements.
Identify Jupyter deployment use-cases as targets for Jupyter Security Best Practices documentation. Example use-cases include supercomputing centers, campus research clusters, workshops, small scientific projects, etc. Prioritize these use-cases based on which audiences would benefit most from new security documentation.
Write Jupyter Security Best Practices documentation for high priority use-cases identified above. Work through other use-cases as time permits.

The Jupyter Security Best Practices documentation produced by this engagement will be shared with Project Jupyter for inclusion in their documentation, and also presented at the workshop.

Here’s how you can get involved and learn more:

The security working group meets every other Friday. You can follow and open issues the repository for public questions and meeting minutes. At this weeks meeting, our Trusted CI colleagues presented an evolving census of all Jupyter-related security documentation: Watch for an upcoming Discourse post about it!
As always, you can send your questions and concerns about security to security@ipython.org to reach out to our security team.

We always welcome feedback, questions, and help regarding security in Jupyter. Here is a link to the original Trusted CI blog post that this blog post was based upon (with permission):

https://blog.trustedci.org/2021/08/engagement-with-jupyter.html

Jupyter’s role in #ChaosDB

2021-09-01T21:43:00+00:00

On August 26 it was revealed that a misconfiguration in Microsoft’s internal deployment of CosmosDB using Jupyter would allow attackers to access all customer data. Fortunately, they report no evidence that customer data was compromised.

Nonetheless, articles onlines, like Ars Technica’s and Reuter’s have strong headlines associated Jupyter, for example “Worst cloud vulnerability you can imagine.”

This can be especially alarming for our community as no details on the vulnerability have been released yet, and members of our community wonder about Jupyter’s possible role in this vulnerability.

What the Jupyter team knows

We learned about the CosmoDB vulnerability at the same time as everyone else; we had no prior notice, and received no privileged communication about this issue. We have not seen any evidence suggesting this relates to a vulnerability in Jupyter itself, as opposed to a misconfiguration of Microsoft’s internal services.

We also had no prior interaction with the Microsoft team about their internal Jupyter deployment in CosmoDB.

From the descriptions posted by Wiz and Microsoft, there is no suggestion of any vulnerability in Jupyter itself, and rather expect that Jupyter was used as convenient shell to exploit a vulnerability in the configuration of Microsoft’s internal services, but we have no information beyond what is publicly available to support that claim.

What are we doing internally

Even if Jupyter does not have a vulnerability to fix, it is often possible for us to warn end users when risky configurations options are set. For example, if you try to login to JupyterHub over a non https connections, you will a see a warning.

JupyterHub warning about login over unsecured HTTP

We are preparing for the full information release of #ChaosDB details, to see if there are any relevant safeguards and warnings to implement on the Jupyter side. We are also trying to reach the involved Microsoft Security Team personally to know whether there are steps we can take before public disclosure.

In the meantime you can contribute and get involved:

The security working group meets every other Friday. You can follow and open issues the repository for public questions and meeting minutes.
You can send your questions and concerns about security to security@ipython.org to reach out to our security team.

We always welcome feedback, questions, and help regarding security in Jupyter.

CVE-2021–32797 and CVE-2021–32798 Remote Code execution in JupyterLab and Jupyter Notebook

2021-08-09T20:05:00+00:00

TL:DR; All recent JupyterLab and Notebook versions are susceptible to a attack where a maliciously crafted notebook can trigger arbitrary code execution when a user views these malicious files.

We strongly advise all users to deploy the new version of JupyterLab and Jupyter Notebook.

Jupyter Notebook 6.4.1 or above, 5.7.11 or above.

Jupyter Lab 3.1.4 or above, 3.0.17 or above, 2.3.2 or above, 2.2.10 or above , 1.2.21 or above

This blog post will be updated with links to the various patches, exploit and disclosure later once the final links are available.

Jupyter Security Model

Jupyter Notebook act as a REPL (Read Eval Print Loop) in a browser, our main goal is to expose as many functionalities to our users, with the least restrictions. We also want users to be able to share their results with other, and let everyone be capable of reproducing the result.

When receiving an untrusted notebook from a potentially malicious source we still want users to be able to inspect a notebook without risks, our approach is that an untrusted notebook has restrictive capabilities until all cells have been manually inspected and explicitly run by a user, or the notebook is explicitly marked as trusted. If one finds a way to bypass this trust mechanism, a notebook might be able to execute code in the browser at at a time where a user is not expecting execution to occur.

This is what happen in these particular CVEs, where some content of a notebook were improperly handled.

[This part of the blog post will be updated with links to actual reports, and proof of concept once the patched version have reached enough package repositories]

CVE Timeline

We want to thanks Guillaume Jeanne (Google), and Timo Schmid (Google) for the vulnerability report and helping us through the fixing process.

Thursday, 15 Jul 2021 07:11:13 -0700 (PDT): Initial question about security issue disclosure on security@ipython.org (no specific on the vulnerability)
Tuesday, 20 Jul 2021 05:52:09 -0700 (PDT): Actual Vulnerability Report.
Tuesday, 20 Jul 2021 : Open relevant GitHub security advisory on Notebook and JupyterLab Repositories
Thursday, 5 August 2021 : First releases with patched version on PyPI.
Monday, 9 August : publication of this blog post and publish security advisory on GitHub.
[Further item may be added to list publication by downstream repositories, like conda, conda-forge, debian…, contact us to add an item]

What we learned

Dealing with Security vulnerability in Jupyter and more generally in Open-Source is far from easy. We initially thought about treating the Notebook and Lab CVE separately but they are/were too similar and the cross discussion too revealing to treat both independently.

As Jupyter is mostly a volunteer based organisation, there is often no contributor responsible to replying to security issues, and when someone steps up they might not be a expert, nor available all the time. I want to give special thanks to Steve Silvester (Apple) , Afshin Darian (Two Sigma), and Zach Sailer (Apple), and Matthias Bussonnier (Quansight) for writing the fixes, planning through the release and notifying stakeholders.

Advance notice to stakeholder is complicated, we know of a few large deployment and have personal connections to a couple organisation, and were able to reached out to let them know critical release would be published. There is an inherent tension between publicly warning our user base that security release would be published, which might push malicious actor to closely survey the codebase changes and re-derive the attack vectors, and publishing the release first, with the details later. Especially since we are trying to be transparent in our communication, security fixes are the opposite of our normal communication workflow.

Our communication process is imperfect. We have 2 mailing list for security-related discussion. The first one – security@ipython.org – has only a couple of members all core contributors and can receive email from the outside, it is used for triage. It receive a high number of spam as this is public email. As it has only a few members and we are all busy, mail can slip through. The second mailing list is slightly larger, and used for internal announcement for stakeholder. It has a fairly open membership model, (ask a Jupyter developer if you can be on it, and the reason why and we’ll likely add you), though it’s content seem to be ignored (it even lands on my spam folder, not sure why).

What we’ll do better

In order to attempt to better react and be proactive with respect to security we are attempting to form and new security-focused subproject/workgroup to educate and have procedure for everything security related. We welcome your involvement and feedback in how to improve Jupyter security and how to better involve the community.

Open Redirect Vulnerability in Jupyter notebook, JupyterHub

2019-03-28T14:03:00+00:00

Update: notebook 5.7.7 and JupyterHub 0.9.5 contained incomplete fixes for this issue. 5.7.8 and 0.9.6 are released with more complete fixes.

JupyterHub ≤ 0.9.5 and Notebook ≤ 5.7.8 are affected. Versions 0.9.6 and 5.7.8 are released with fixes. Upgrade with pip or conda:

pip install --upgrade 'notebook>=5.7.8'
pip install --upgrade 'jupyterhub>=0.9.6'

conda install -c conda-forge 'notebook>=5.7.8'
conda install -c conda-forge 'jupyterhub>=0.9.6'

notebook 5.7.8 also fixes some compatibility issues and regressions introduced in 5.7.5 and 5.7.6, especially on some Windows systems. If you use the jupyterhub helm chart, version 0.8.2 upgrades JupyterHub to 0.9.6.

What is an Open Redirect Vulnerability?

Login pages tend to take a parameter for redirecting back to a page after successful login, e.g. /login?next=/notebooks/mynotebook.ipynb, so that you aren’t disrupted too much if you try to visit a page, but have to authenticate first. An Open Redirect Vulnerability is when a malicious person crafts a link pointing to the login page of a trusted site, but setting the “redirect after successful login” parameter to send the user to their own site, instead of a page on the authenticated site (the notebook or JupyterHub server), e.g. /login?next=http://badwebsite.biz. This doesn’t necessarily compromise anything immediately, but it enables phishing if users don’t notice that the domain has changed, e.g. by showing a fake “re-enter your password” page. Servers generally have to validate the redirect URL to avoid this. Both JupyterHub and Notebook already do this, but the validation didn’t take into account all possible ways to redirect to other sites, so some malicious URLs could still be crafted to redirect away from the server (the above example does not work in any recent version of either package). Only certain browsers (Chrome and Firefox, not Safari) could be redirected from the JupyterHub login page, but all browsers could be redirected away from a standalone notebook server.

This vulnerability has been assigned CVE-2019–10255. This post will be updated when it has been assigned. Thanks to Ronak Odhaviya for reporting the issue. You can report security issues by emailing ipython-security@googlegroups.com.

Jupyter notebook XSSI security fix

2019-03-09T20:46:00+00:00

We have just released Jupyter notebook 5.7.6 with a security fix for a cross-site inclusion (XSSI) vulnerability, where content from a Jupyter server could be included in another page if the visitor is logged in to the Jupyter server and the author of the page knows the URL of the server and the path within the server’s notebook directory that they would like to include. Further, it has been demonstrated with the Internet Explorer browser that some content from the accessed file can be retrieved by the attacking page. This has not yet been demonstrated with other browsers, however.

To upgrade:

pip install --upgrade 'notebook>=5.7.6'

or conda:

conda install 'notebook>=5.7.6'

This vulnerability was reported by the HackerOne hacker Abhishek Bundela, via Jonathan Kamens at Quantopian. The patch was developed by Min Ragan-Kelley with help from Devdatta Akhawe. Jupyter is grateful to Quantopian’s bug bounty program, which has found and reported this and other security flaws in Jupyter.

This vulnerability has been assigned CVE-2019–9644.

Jupyter Notebook security fixes

2018-11-19T22:20:00+00:00

Two security issues have been found and fixed this week, where untrusted javascript could be executed if malicious files could be delivered to the users system and the user takes specific actions with those malicious files.

The first allowed nbconvert endpoints (such as Print Preview) to render untrusted HTML and javascript with access to the notebook server. This is fixed in notebook 5.7.1. All notebook versions prior to 5.7.1 are affected. Thanks to Jonathan Kamens of Quantopian for reporting. This issue has been assigned CVE-2018–19351.

The second issue allowed maliciously crafted directory names to execute javascript when opened in the tree view. This is fixed in notebook 5.7.2. All versions of notebook from 5.3.0 to 5.7.1 are affected. Thanks to Marvin Solano Quesada for reporting. This issue has been assigned CVE-2018–19352.

You can check your version of the notebook package by issuing the following command:

jupyter notebook --version

Whether you are using classic notebook, JupyterLab or any other notebook server extensions, we recommend that you update the notebook package with :

pip install --upgrade notebook

or if you are using conda-forge

conda upgrade notebook

Thanks especially to Jonathan and Marvin for reporting these issues! If you find a security issue in a Jupyter project, please report it to security@ipython.org.

Security fix for Jupyter Notebook

2018-07-18T04:31:00+00:00

We have just released Jupyter Notebook 5.6.0. This release fixes a vulnerability that could allow a maliciously crafted notebook to execute JavaScript when it is opened, bypassing the trusted-notebook mechanism.

We recommend updating the notebook immediately, via pip:

pip install notebook>=5.6.0

or conda:

conda install notebook>=5.6.0

Affected versions: all releases prior to 5.6.0

JupyterLab users are affected, independent of the version of JupyterLab itself. Upgrading the notebook package to 5.6.0 resolves the issue for users of both JupyterLab and the classic notebook.

A CVE has been requested for the vulnerability. Release notes for 5.6.0 and this post will be updated as the CVE is assigned. More details of the vulnerability will be released in 30 days, on August 16, 2018.

Security reports for Jupyter are greatly appreciated. You can report security issues to security@ipython.org.

Thanks to Jonathan Kamens for reporting this issue to the security list.

[Update July 28] The vulnerability have been assigned number CVE-2018–1999024.

[Update August 16] MathJax versions prior to version 2.7.4 contains a Cross Site Scripting (XSS) vulnerability in the \unicode{} macro that can result in potentially untrusted Javascript running within a web browser, for example at notebook load. Notebook 5.6.0 ships with an updated mathjax version 2.7.4 which fixes this vulnerability.

Security fix for JupyterHub GitLab OAuthenticator Group Whitelists

2018-02-16T22:12:00+00:00

This vulnerability has been assigned CVE-2018–7206

If you are using JupyterHub with the GitLab OAuthenticator and its gitlab_group_whitelist support, there is a security issue where the authenticator will allow users outside your intended group whitelist to create accounts. A fix has been released as OAuthenticator 0.6.2 and 0.7.3. No other authentication mechanism, including GitLabOAuthenticator without using the group whitelist feature, is affected. If you are using GitLab authentication with group whitelist support, upgrade oauthenticator immediately:

python3 -m pip install --upgrade oauthenticator

Thanks to Joseph Weston for reporting the issue and providing the fix.

Timeline (all times UTC):

2018–02–16 09:51 Joseph Weston reports security issue to the Jupyter security list

2018–02–16 16:08 Fix is verified and applied to oauthenticator master

2018–02–16 21:52 oauthenticator 0.7.3 and 0.6.2 are released with the fix

2018–02–18 03:02 CVE-2018–7206 assigned

Public Notebooks and Security

2017-11-28T19:33:00+00:00

tl;dr: don’t disable notebook authentication!

Let’s chat a little bit about public Jupyter notebook servers and security. A lot of folks run notebook servers that are publicly accessible, whether they are the access point to a cloud server or remote access to their home or office computer. This is great! It is important to keep in mind that, since arbitrary code execution is the main point of IPython and Jupyter, running a publicly accessible server without authentication or encryption is a very bad idea indeed. Prior to notebook 4.3, this was the default behavior of Jupyter, which has led to a lot of insecure notebook servers running on cloud services. One aspect that may not be apparent is that people can find your public notebook server, especially if it is on one of the popular cloud providers. Systematic port scans will turn up notebook servers, especially for those running on the default port of 8888. And Jupyter has become popular enough (🎉) that we know people are doing this (😠). Running a publicly accessible notebook server without authentication is making your computing resources free for the world to use.

The highlights to keep in mind:

Always enable a password or token for publicly accessible notebook servers (this includes shared computers)
Use HTTPS for authenticated notebooks over the Internet
Unsecured public notebook servers are discoverable
Running on a cloud service should be treated as if it’s publicly accessible

The first two points shouldn’t be new information, and anyone following the documentation should be adding basic authentication when exposing a server to the public. If you are already accessing a notebook server over https with a password or token, you have nothing to worry about. However, if you are running unsecured notebook servers on the Internet, please stop and enable a password. The latter points are important and may not be obvious, but the gist is: don’t disable notebook authentication, even if you think your bases are covered via other means.

In notebook 4.3, a token is enabled by default, making it a little bit more inconvenient to run a totally insecure notebook server. We can’t feasibly require HTTPS by default, but free, trusted HTTPS has never been easier, thanks to LetsEncrypt. If you can’t assign a domain name to your server, self-signed certificates can be used, with some caveats (notably: Safari requires self-signed certificates be trusted at the system level before it will allow websocket connections). For shared deployments, you can also use JupyterHub, which allows you to authenticate notebooks via the system (PAM) or OAuth providers such as GitHub, Google, etc.

Be safe out there.

Security release: Jupyter Notebook 4.3.1

2016-12-22T02:25:00+00:00

We have just released Jupyter Notebook 4.3.0 and 4.3.1 with some important security fixes.

You can check out the changelog for more details on the many fixes and improvements. I’m going to focus on the security changes in this post.

4.3.0: Token authentication

The biggest change in 4.3 is the addition of token-based authentication, which is enabled by default. Several of the security issues the notebook has had over the years would have been avoided if the notebook ran with authentication by default. We did not do this for a long time, because the process of enabling and entering a password on a localhost-only web application was deemed too cumbersome, and the risks too small, given that it listened only on localhost. With automatic token authentication, I think we have a solution that should be convenient enough for most users that we can now switch to enabling authentication by default.

If you use Jupyter in its default configuration, which is to open your browser automatically when you type jupyter notebook, this shouldn’t have much impact on your daily work. In this case, a one-time token is generated, and your browser opens with this in the URL. That token is immediately consumed, and your browser will be authenticated, storing the information in a cookie for future requests.

If you access the notebook without authentication, you will see this page:

This may happen if you switch browsers, or use the notebook with the --no-browser option, in which you will need to enter the token manually the first time you connect to a server with a given browser. This can be done at the login page above, or via a URL containing the token. The notebook server logs this URL when it starts, so you can paste the URL into your browser:

[C 16:11:17.581 NotebookApp]
    Copy/paste this URL into your browser when you connect for the first time,
    to login with a token:
        http://localhost:8888/?token=20abd368...

After you have logged in with this token just once, a cookie is set and used thereafter, even across restarts of the notebook server. So you shouldn’t need to deal with the token after the first time you have used the notebook on a given machine, until/unless you switch browsers or launch new notebook servers on different ports. This does mean that cookies are required for authenticated access to notebooks, and clearing cookies means needing to login again.

At any time, you can see all of your current notebook servers with their token-authenticated URLs by running the jupyter notebook list command:

$ jupyter notebook list
Currently running servers:
http://localhost:8888/?token=1234... :: /Users/you/notebooks

We didn’t communicate the information about token authentication very well in 4.3.0, and I apologize for that. 4.3.1 should make the token behavior much clearer, with more information in both the login form and the notebook log output about how to use the tokens and when you need them. You can see the docs for more details. We’re always open to improvements, so please open an Issue if you are having trouble.

4.3.1

4.3.1 follows shortly after 4.3.0, with a fix for a CSRF vulnerability (CVE-2016–9971), affecting users of the Firefox or Microsoft (IE, Edge) browsers, and any other browsers that do not set the Origin header on cross-site forms. WebKit and Blink based browsers like Safari and Chrome are not affected. The effect of this vulnerability is the ability of forms on malicious websites visited by the user to spawn new kernels and create empty, untitled files on the user’s notebook server. CORS protections already in place prevent further access to these kernels and editing the content of any files.

Summary:

CVE-2016–9971
Affected notebook versions: all notebook releases < 4.3.1
Affected users: Users of Firefox or Microsoft browsers, or other browsers that do not set the Origin header on forms.
Results: Visiting malicious pages with these browsers could result in unauthorized launch of new kernels or creation of empty, untitled files on the user’s notebook server
Fix: Upgrade to notebook-4.3.1, which uses an xsrf token via cookies to validate the origin of forms. See tornado docs for details.

Update: practical effects of xsrf for extensions

This note was omitted when first posted.

The use of the xsrf token affects existing extensions / etc. that work directly with the notebook server via REST API. To make requests to the rest API, the _xsrf cookie must be sent back to the server in the X-XSRF-Token header of API requests, for example:

function _get_cookie(name) {
  // from tornado docs: http://www.tornadoweb.org/en/stable/guide/security.html
  var r = document.cookie.match("\\b" + name + "=([^;]*)\\b");
  return r ? r[1] : undefined;
}

function _add_xsrf_token(settings) {
  // Adds xsrf token header to jquery ajax settings
  settings = settings || {};
  var xsrf_token = _get_cookie('_xsrf');
  if (xsrf_token) {
    if (!settings.headers) {
      settings.headers = {};
    }
    settings.headers['X-XSRFToken'] = xsrf_token;
  }
  return settings;
}
function ajax(url, settings) {
  // like $.ajax, but ensure xsrf token is added to headers
  settings = _add_xsrf_token(settings);
  return $.ajax(url, settings);
};

This code will also work for any previous version of the notebook, where the xsrf cookie will be undefined and ignored.

If you’re using fetch, you’ll need to set credentials: true as well so that the Cookie header is set.

var xsrfToken = _get_cookie('_xsrf')
fetch("http://127.0.0.1:8888/api/contents/",
  {
    method: "POST",
    credentials: "include",
    headers: {
      "X-XSRFToken": xsrfToken,
      "Content-Type": "application/json",
    },
    body: { name: "Test.py" }
  }
)

ipywidget security release

2016-09-26T23:37:00+00:00

Hello Jovyan,

A version of ipywidget has been released, which fixes important security issues. Please upgrade ipywidgets as soon as you can:

$ pip install ipywidgets --upgrade

Please do so in all your environments.

More details follow. We requested a CVE number and were asked to wait before any public disclosure of the vulnerability. As we have now been delaying the disclosure for over a resonable time, and we’re still waiting for the CVE number, we decided to still disclose the vulnerability. This post will be updated once/if a CVE number is made available.

[Update Dec 15, 2016]

A CVE number cannot be assigned for lack of sufficient information. No explanation of what more is needed was provided.

Description

ipywidgets version 5.1.5 (widgetsnbextension 1.2.3) fixes a security vulnerability (CVE-PENDING) which affects the usage of ipywidgets in conjunction with the Jupyter Notebook.

Affected versions

ipywidgets version 5.0.0 ≤ V ≤ 5.1.4 (widgetsnbextension < 1.2.3).

Only users who installed ipywidgets using pip or from source on the GitHub repository are affected.

Anaconda users are unaffected because the vulnerable version of ipywidget has never been released to the default conda channel.

Resolution

We released ipywidgets version 5.1.5 (widgetsnbextension version 1.2.3).

You can check whether your system is affected by running the following command from a Python or IPython prompt:

>>> from distutils.version import LooseVersion as V
>>> import ipywidgets
>>> if V('5.0.0') <= V(ipywidgets.__version__) < V('5.1.5'):
        print("Upgrade ipywidgets to 5.1.5")

If your system is vulnerable, you will see the following output:

Upgrade ipywidgets to 5.1.5

If your system is vulnerable please upgrade to ipywidgets version 5.1.5. Use the following command to install:

$ pip install "ipywidgets>=5.1.5"

$ conda install "ipywidgets>=5.1.5"

Technical details

The vulnerability was discovered following an investigation of a potential vulnerability reported by Brian Granger to the ipython-security mailing list (security@ipython.org) on May 5.

The reason for such behavior was determined on May 5 by Matthias Bussonnier.
A fix was proposed written and reviewed, then merged into the development branch on May 20, and a non vulnerable version released on May 25.

A widget snapshotting feature introduced in ipywidgets 5.0.0 allowed untrusted javascript code to execute in an untrusted notebook on loading and saving of a notebook. A well crafted notebook could execute arbitrary code with the rights of the current user in the context of the page, the notebook server, and available kernels.

We recommend immediate upgrade of the ipywidgets package.

There is no simple configuration option that could mitigate the system for vulnerability. The user must upgrade to ipywidget version 5.1.5 or downgrade to 4.x.

Future Plan

The security issue resulted from the seemingly harmless combination of calls:

json = cell.get_json()
json = update_json(json)
cell.clear_output()
cell.from_json(json)

The clear_output() method has as a consequence to mark the cell as trusted (as it has no output that can potentially execute javascript). This is followed by the next call which can trigger JavaScript execution in the page context.

We plan on improving the notebook API so that clear_output() does not change the trusted status of a cell (or a notebook), to prevent mistakes like this from having security consequences. This will lead to the slight behavior change that an empty cell with no output can be untrusted.

Doing better next time

We learned that we are not completely ready for fast release of security fixes. The time from vulnerability discovery to available fix and release could have been better. The announcement was delayed while waiting for a CVE number which is still not there. We will consider a sorter timescale to publication even if we don’t get assigned a CVE number quickly. The standard seem to be 90 days from security vulnerability report, we might end up selecting this as well.

We encourage users who find possible security issues to notify security@ipython.org.

Thanks!

Notebook 4.2.2: Security fix

2016-08-03T20:47:00+00:00

TL;DR: upgrade to notebook 4.2.2

We just released notebook 4.2.2 with a few bugfixes and one important security fix.

We (specifically Steve Sylvester) have found a longstanding security issue in the Notebook, regarding output of untrusted notebooks being able to execute code when the notebook is opened.

The vulnerability has been assigned the identifier CVE-2016-6524.

Affected versions:

2.0 ≤ IPython < 4.0 (all IPython notebook versions, starting with the introduction of the concept of untrusted output)
notebook ≤ 4.2.1

Solution:

Upgrade to notebook 4.2.2

Specifically:

pip install --upgrade notebook
or conda install notebook (once conda channels propagate the release)

If you cannot upgrade to 4.2.2, we have prepared a backported patch for the 2.x and 3.x branches of IPython, but have no current plans for making a new release of these branches.

Details

The vulnerability was reported on July 26, and a fix proposed on the same day. After some review and testing of the patch and a check for similar vulnerabilities, on August 3 a CVE was assigned and the 4.2.2 release made immediately thereafter.

The goal of Jupyter notebooks is executing code, and outputs being able to execute code is one of the key features that enables people to do cool stuff. However, we don’t want notebooks written by not-you to be able to execute code as you on your computer as soon as you open them. For this reason, we have the concept of ‘trusted notebooks’ (introduced in IPython 2), which are notebooks where all output has been produced by you. The main result is that if you get a notebook from someone else with fancy dynamic javascript output, you might see things like:

<Javascript uninteresting repr...>

instead of the fancy visualization. Once you either execute the notebook yourself or explicitly trust the notebook from the File menu, you can see the real results.

When loading output from an untrusted notebook, we take one of three actions:

the output is unsafe, and ignored (Javascript)
the output is potentially unsafe, and sanitized (HTML)
the output is safe, and displayed regardless of trust

It’s that third option of “safe” outputs where things went a bit awry. Safe outputs should be outputs that cannot run code in the browser. This includes plain-text output, which we reliably escape, and raster images, such as pngs and jpegs. So far, so good. It also includes latex, which ought to be like plain text, in that it’s properly escaped before being put on the page to be rendered by MathJax. This is where we went wrong. We were putting latex output on the page with jQuery’s $.append, which puts elements on the page verbatim. In this way, if the output that claimed to be latex was actually HTML with script tags and such, it would be able to execute code. The right thing to do (all along) was to use the safe $.text, which escapes HTML entities before putting things on the page.

So that’s the fix.

I’m a bit surprised that we didn’t have bugs caused by inequalities and such in equations being mistakenly interpreted as HTML tags.

See our security docs for further details on the security model in Jupyter Notebooks.

If you find a security issue with the notebook or other Jupyter components, please let us know at [email protected]