Report from the Jupyter Security Working Group security tooling sprint

Wed, 08 Apr 2026 00:00:00 +0000

The Jupyter Security Working Group recently held a Security Tooling Sprint. It was a timely event given the recent spate of software supply chain attacks across the tech world.

The sprint covered two main areas:

Governance and strategy — conversations about responsibility and accountability in the face of AI, with emphasis on ensuring humans are ultimately responsible for code committed to Jupyter subprojects. The group also discussed how security could benefit from working group members regularly attending subproject meetings like the JupyterHub Collaboration Cafes.
Automation and tools — the group evaluated several tools for improving security posture across the Jupyter ecosystem. Here are a few that stood out:
- Semgrep as an alternative vulnerability scanner to CodeQL
- Grype, Checkov, and Kubescape for cloud infrastructure misconfiguration checks
- Schemathesis and restler-fuzzer for API fuzz testing

One challenge we discussed was how blindly running security scanning tools generates many false positives. There’s real effort needed to tune these tools for each project’s edge cases before they’re useful in automation. On a related note, we discussed the increase in AI-generated (or AI-assisted) vulnerability and security reports, and the challenges associated with sifting through all of those pieces of information.

Acknowledgements #

Thanks to the jupyter security working group for providing leadership and organizing, in particular Joe Lucas!
Thanks to the Jupyter Foundation for funding community meetings like these.

Security report for jupyter-server-proxy: CVE-2024-28179

Tue, 19 Mar 2024 00:00:00 +0000

What happened? #

A few weeks ago, the JupyterHub team discovered a security vulnerability in the jupyter-server-proxy package that would allow potential unauthenticated access to a JupyterHub via WebSockets, allowing unauthenticated users to run arbitrary code on the JupyterHub. jupyter-server-proxy is used by many communities to provide alternative user interfaces like RStudio and remote desktops.

This vulnerability was detected by the JupyterHub team, with leadership from 2i2c’s engineers. It was resolved through upstream contributions to the JupyterHub project, and we have deployed a fix that mitigates this vulnerability for all the hubs 2i2c manages.

Does this impact my 2i2c community hub? #

We do not believe that any of 2i2c’s communities were impacted by this vulnerability, and a patch has now been pushed to all community hubs to resolve this issue.

If your community was vulnerable to this problem, you might experience slightly slower startup latency while we work out a long-term solution.

Since this is a vulnerability in the docker image used by our communities, we will be reaching out over the next few weeks to put a more permanent fix in place.

Where can I learn more? #

See the JupyterHub security advisory for CVE-2024-28179 for more information about the security vulnerability, including details on the mitigation we have put in place to protect our communities.

Conclusion #

We’re grateful that the JupyterHub community was quick to acknowledge, respond, and resolve this security vulnerability after it was brought to their attention. We’re also proud that 2i2c’s engineers helped the JupyterHub team throughout the process.

This allowed our team to resolve the problem before it impacted any of 2i2c’s communities. Because 2i2c community infrastructure is managed in a central location, we were able to resolve this for over 80 communities with a single team rather than expecting each community to learn about and fix this problem on their own.

We also believe this reflects the healthy upstream relationships that we hope to encourage with our team’s Open Source strategy and practices. By working with the JupyterHub community and pushing changes upstream, we’ve resolved this issue for any user of jupyter-server-proxy, not just 2i2c’s own ecosystem. In particular, because of 2i2c’s position running hubs for many communities via Kubernetes, we were able to identify a solution that did not require every user image to be updated (as described in section For JupyterHub admins of Z2JH installations).

We believe that all of these lead to a healthier, safer ecosystem of open source tools ❤️.