CVE-2024-28179 Overview
Jupyter Server Proxy is a popular extension that allows users to run arbitrary external processes alongside their Jupyter notebook servers and provides authenticated web access to these processes. A critical authentication bypass vulnerability exists in versions prior to 3.2.3 and 4.1.1, where the proxy failed to properly check user authentication when handling websocket connections. This flaw allows any attacker with network access to the Jupyter server endpoint to gain unauthenticated access to websocket endpoints configured through Jupyter Server Proxy.
Critical Impact
This vulnerability enables unauthenticated remote access to websocket endpoints, which in many deployments leads to arbitrary code execution due to how affected applications utilize websockets for interactive functionality.
Affected Products
- Jupyter Server Proxy versions prior to 3.2.3
- Jupyter Server Proxy versions 4.x prior to 4.1.1
Discovery Timeline
- 2024-03-20 - CVE-2024-28179 published to NVD
- 2025-02-21 - Last updated in NVD database
Technical Details for CVE-2024-28179
Vulnerability Analysis
The vulnerability stems from missing authentication enforcement in the websocket handling code within jupyter_server_proxy/handlers.py. While HTTP requests to the proxy were properly authenticated, websocket upgrade requests bypassed this authentication check entirely. This created a significant security gap since many applications proxied through Jupyter Server Proxy rely heavily on websockets for real-time communication, including terminal access and interactive computing environments.
The issue is classified as CWE-306 (Missing Authentication for Critical Function), which accurately describes the nature of the flaw. Websocket connections are particularly sensitive in Jupyter environments because they often provide direct access to shell terminals, code execution environments, and other interactive features that assume authenticated access.
Root Cause
The root cause lies in the ProxyHandler class implementation, which did not implement a prepare() method to enforce authentication before processing websocket upgrade requests. In Tornado (the web framework used by Jupyter), the prepare() method is called before any other handler method, making it the appropriate location to enforce authentication across all request types, including websocket upgrades.
Attack Vector
An attacker with network access to a vulnerable Jupyter Server Proxy instance can establish an unauthenticated websocket connection to any proxied service. The attack requires no user interaction and can be executed remotely over the network. The exploitation path involves:
- Identifying a Jupyter Server instance with Server Proxy enabled
- Crafting a websocket upgrade request to a proxied endpoint
- Bypassing authentication and gaining direct access to the proxied service
- Executing commands or accessing data through the websocket connection
# Security patch implementing authentication enforcement for websocket requests
# Source: https://github.com/jupyterhub/jupyter-server-proxy/commit/764e499f61a87641916a7a427d4c4b1ac3f321a9
async def open(self, port, proxied_path):
raise NotImplementedError("Subclasses of ProxyHandler should implement open")
+ async def prepare(self, *args, **kwargs):
+ """
+ Enforce authentication on *all* requests.
+
+ This method is called *before* any other method for all requests.
+ See https://www.tornadoweb.org/en/stable/web.html#tornado.web.RequestHandler.prepare.
+ """
+ # Due to https://github.com/jupyter-server/jupyter_server/issues/1012,
+ # we can not decorate `prepare` with `@web.authenticated`.
+ # `super().prepare`, which calls `JupyterHandler.prepare`, *must* be called
+ # before `@web.authenticated` can work. Since `@web.authenticated` is a decorator
+ # that relies on the decorated method to get access to request information, we can
+ # not call it directly. Instead, we create an empty lambda that takes a request_handler,
+ # decorate that with web.authenticated, and call the decorated function.
+ # super().prepare became async with jupyter_server v2
+ _prepared = super().prepare(*args, **kwargs)
+ if _prepared is not None:
+ await _prepared
+
+ # If this is a GET request that wants to be upgraded to a websocket, users not
+ # already authenticated gets a straightforward 403. Everything else is dealt
+ # with by `web.authenticated`, which does a 302 to the appropriate login url.
+ # Websockets are purely API calls made by JS rather than a direct user facing page,
+ # so redirects do not make sense for them.
+ if (
+ self.request.method == "GET"
+ and self.request.headers.get("Upgrade", "").lower() == "websocket"
Detection Methods for CVE-2024-28179
Indicators of Compromise
- Unexpected websocket connections to Jupyter Server Proxy endpoints from external or unauthenticated sources
- Access logs showing websocket upgrade requests without corresponding authentication tokens or session cookies
- Unusual command execution patterns or data access through proxied services
- Connection attempts to proxy endpoints from IP addresses not associated with legitimate users
Detection Strategies
- Monitor web server access logs for websocket upgrade requests (HTTP header Upgrade: websocket) to Jupyter Server Proxy paths that lack authentication credentials
- Implement network-level detection for connections to Jupyter ports (typically 8888) that immediately initiate websocket handshakes without prior authentication flows
- Review Jupyter server logs for connections to proxied services that bypass normal user authentication workflows
- Deploy web application firewalls configured to detect unauthenticated websocket upgrade attempts
Monitoring Recommendations
- Enable detailed logging on Jupyter Server instances to capture all connection attempts and authentication states
- Configure alerting for websocket connections from unexpected IP ranges or during unusual time periods
- Implement baseline analysis of normal websocket traffic patterns to detect anomalous access attempts
- Monitor for lateral movement indicators if Jupyter environments have access to sensitive internal resources
How to Mitigate CVE-2024-28179
Immediate Actions Required
- Upgrade Jupyter Server Proxy to version 3.2.3 or 4.1.1 immediately to address this vulnerability
- Audit access logs for evidence of exploitation, particularly unauthenticated websocket connections
- Restrict network access to Jupyter Server instances using firewalls or network segmentation
- Review and limit which services are exposed through Jupyter Server Proxy to reduce the attack surface
Patch Information
The Jupyter development team has released patched versions that implement proper authentication enforcement for all request types, including websocket upgrades. The fix adds a prepare() method to the ProxyHandler class that enforces authentication before any request handling occurs.
Fixed Versions:
- Version 3.2.3 for the 3.x branch
- Version 4.1.1 for the 4.x branch
Patches are available through the standard Python package managers. For detailed technical information, see the GitHub Security Advisory (GHSA-w3vc-fx9p-wp4v).
Workarounds
- If immediate patching is not possible, restrict network access to Jupyter Server instances to trusted IP ranges only
- Disable or remove Jupyter Server Proxy extension temporarily if not required for operations
- Place the Jupyter Server behind an authenticating reverse proxy that enforces authentication on all requests including websocket upgrades
- Monitor for and block websocket upgrade requests that lack proper authentication headers at the network perimeter
# Upgrade Jupyter Server Proxy to patched version
pip install --upgrade jupyter-server-proxy>=3.2.3
# For 4.x branch users
pip install --upgrade jupyter-server-proxy>=4.1.1
# Verify installed version
pip show jupyter-server-proxy | grep Version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

