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

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 ❤️.