A new security vulnerability has been discovered in the popular Jupyter Server Proxy extension, tracked as CVE-2024-35225. This bug exposes users to reflected cross-site scripting (XSS) attacks via the /proxy endpoint. If you use Jupyter environments, especially for research or sensitive computations, understanding this issue and how to fix it is critical.

This post breaks down how the vulnerability works, shows real exploit examples, and explains how to protect your servers. Let’s dig in.

What is Jupyter Server Proxy?

Jupyter Server Proxy is a server extension for Jupyter notebooks and JupyterLab. It allows users to launch and access external web applications (like TensorBoard, RStudio, and custom web apps) side-by-side with their notebooks, all authenticated through the Jupyter interface.

This means users can easily try out tools without worrying about separate logins or exposed ports.

4.x: All versions prior to 4.2.

- Vulnerable Endpoint: /proxy/<host>

How it Works

The /proxy endpoint expects a valid <host> parameter, like /proxy/808/. But when an attacker provides an invalid host value that includes JavaScript code, the server responds with an error message containing the unsanitized value. This allows attackers to inject arbitrary scripts.

> Any user who clicks a specially crafted link can have arbitrary JavaScript executed in their browser, potentially compromising their Jupyter session.

Here’s a minimal, real-world exploit

1. The Attacker’s Goal: Send a victim (authenticated Jupyter user) a link, for example in an email or chat.

2. The Payload: By crafting the host path, the attacker embeds the payload in the error response. For example:

/proxy/<script>alert('XSS!')</script>


http(s)://your-jupyter-server.com/user/myuser/proxy/<script>alert('XSS!')</script>

When the victim is authenticated and clicks this link, Jupyter Server Proxy returns an error page with their injected <script>, which runs immediately in the browser context. This could allow privilege escalation, session hijack, command execution, and more.

Error page includes unsanitized host

<h1>Error: Failed to connect to <script>alert('XSS!')</script></h1>

Why is This so Dangerous?

If a user is logged into a Jupyter server, any code the attacker injects via <script> tags will run with the user’s browser permissions. An attacker may:

Shadow user activity and exfiltrate data

If your JupyterLab is exposed to the internet or multi-user, you should treat this as critical.

References & Official Announcement

- GitHub Advisory - GHSA-7h64-mg84-7722
- Commit that fixes the bug
- CVE record at NVD

Or just

pip install --upgrade jupyter-server-proxy

Solution 2: Workaround if Upgrade NOT Possible

If you can’t upgrade for some reason, disable jupyter-server-proxy:

jupyter serverextension disable --sys-prefix jupyter_server_proxy

OR, for some setups

jupyter nbextension disable --py --sys-prefix jupyter_server_proxy

Note: This will stop users from using integrated apps like TensorBoard. It’s safer (but less featureful) than staying vulnerable.

- Consider network-level restrictions to expose Jupyter only to trusted users/IPs

Conclusion

CVE-2024-35225 is an easy-to-exploit XSS that can have devastating consequences for Jupyter Server users. The fix is simple: *upgrade to the latest version of jupyter-server-proxy*. If you’re running a shared or public-facing Jupyter environment, treat this as an emergency and patch today.

Stay safe and spread the word to your colleagues!

*This post is exclusive for users who want clear, real-world understanding of CVE-2024-35225, with concrete code examples and simple fixes. Bookmark official references for updates as they drop!*

Timeline

Published on: 06/11/2024 22:15:09 UTC
Last modified on: 06/13/2024 18:36:09 UTC