CVE-2025-32428: Jupyter Remote Desktop Proxy RCE Flaw

CVE-2025-32428 Overview

CVE-2025-32428 is an Exposure of Resource to Wrong Sphere vulnerability in Jupyter Remote Desktop Proxy, a component that enables users to run a Linux Desktop environment on JupyterHub. The vulnerability affects versions prior to 3.0.1 when used with TigerVNC as the VNC server implementation. Although jupyter-remote-desktop-proxy was designed to rely on UNIX sockets readable only by the current user since version 3.0.0, the VNC server started by the proxy remained accessible via the network when TigerVNC was in use, creating a significant security exposure.

Critical Impact

Adjacent network attackers can gain unauthorized access to VNC sessions that should have been restricted to UNIX socket communication only, potentially leading to full desktop session hijacking and unauthorized system access.

Affected Products

• Jupyter Remote Desktop Proxy versions prior to 3.0.1 when used with TigerVNC
• JupyterHub deployments utilizing jupyter-remote-desktop-proxy with TigerVNC as the vncserver executable
• Systems where TigerVNC (not TurboVNC) is the default VNC server implementation

Discovery Timeline

• April 15, 2025 - CVE-2025-32428 published to NVD
• April 15, 2025 - Last updated in NVD database

Technical Details for CVE-2025-32428

Vulnerability Analysis

This vulnerability is classified under CWE-668: Exposure of Resource to Wrong Sphere, which describes situations where a product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access. The core issue stems from a behavioral difference between TigerVNC and TurboVNC when handling socket configuration parameters.

The jupyter-remote-desktop-proxy component was updated in version 3.0.0 to use UNIX sockets for VNC communication, which should have restricted access to only the current user. However, TigerVNC does not honor the -rfbport -1 parameter in the same way TurboVNC does. While TurboVNC defaults to not opening a TCP port when using UNIX sockets, TigerVNC continues to bind to a network port, exposing the VNC session to adjacent network attackers.

This vulnerability does not affect users who have TurboVNC configured as the vncserver executable, as TurboVNC correctly defaults to not opening a TCP port when UNIX sockets are specified.

Root Cause

The root cause is the inconsistent handling of network socket configuration between TigerVNC and TurboVNC implementations. The original code assumed that specifying -rfbunixpath would be sufficient to prevent network exposure across all VNC server implementations. However, TigerVNC requires an explicit -rfbport -1 parameter to disable TCP port binding, while TurboVNC does not support this parameter but naturally defaults to the secure behavior.

Attack Vector

The attack vector requires adjacent network access, meaning an attacker must be on the same network segment as the vulnerable JupyterHub deployment. An attacker positioned on the adjacent network can:

1. Scan for exposed VNC ports on systems running jupyter-remote-desktop-proxy with TigerVNC
2. Connect to the exposed VNC session without proper authentication boundaries
3. Gain access to the remote desktop session, potentially compromising sensitive data and system access
4. Leverage the desktop session for further lateral movement within the network

The following code shows the security patch that addresses the vulnerability by explicitly disabling TCP port binding for TigerVNC:

            "vncserver executable not found, please install a VNC server"
        )

+    # TurboVNC and TigerVNC share the same origin and both use a Perl script
+    # as the executable vncserver. We can determine if vncserver is TigerVNC
+    # by searching tigervnc string in the Perl script.
+    #
+    # The content of the vncserver executable can differ depending on how
+    # TigerVNC and TurboVNC has been distributed. Below are files known to be
+    # read in some situations:
+    #
+    # - https://github.com/TigerVNC/tigervnc/blob/v1.13.1/unix/vncserver/vncserver.in
+    # - https://github.com/TurboVNC/turbovnc/blob/3.1.1/unix/vncserver.in
+    #
+    with open(vncserver) as vncserver_file:
+        vncserver_file_text = vncserver_file.read().casefold()
+    is_turbovnc = "turbovnc" in vncserver_file_text

    # {unix_socket} is expanded by jupyter-server-proxy
-    vnc_args = [vncserver, '-rfbunixpath', '{unix_socket}']
+    vnc_args = [vncserver, '-rfbunixpath', "{unix_socket}", "-rfbport", "-1"]
+    if is_turbovnc:
+        # turbovnc doesn't handle being passed -rfbport -1, but turbovnc also
+        # defaults to not opening a TCP port which is what we want to ensure
+        vnc_args = [vncserver, '-rfbunixpath', "{unix_socket}"]

    xstartup = os.getenv("JUPYTER_REMOTE_DESKTOP_PROXY_XSTARTUP")
    if not xstartup and not os.path.exists(os.path.expanduser('~/.vnc/xstartup')):

Source: GitHub Commit

The patch introduces VNC server type detection by reading the vncserver executable and checking for the "turbovnc" string. For TigerVNC installations, it explicitly adds -rfbport -1 to disable TCP port binding. For TurboVNC, it maintains the original behavior since TurboVNC already defaults to not opening a TCP port.

Detection Methods for CVE-2025-32428

Indicators of Compromise

• Unexpected network connections to VNC ports (typically 5900-5999) from systems running JupyterHub
• VNC service bindings on network interfaces where UNIX socket-only communication was expected
• Network traffic analysis showing VNC protocol communications on TCP ports in JupyterHub environments
• Log entries indicating VNC connections from external IP addresses to JupyterHub servers

Detection Strategies

• Monitor for VNC-related TCP port bindings using netstat or ss commands on JupyterHub servers: ss -tlnp | grep vnc
• Implement network segmentation monitoring to detect VNC protocol traffic between network segments
• Deploy intrusion detection rules for VNC handshake patterns on unexpected network paths
• Audit jupyter-remote-desktop-proxy configurations to identify TigerVNC usage

Monitoring Recommendations

• Configure network monitoring tools to alert on VNC protocol traffic outside expected UNIX socket paths
• Establish baseline network behavior for JupyterHub deployments and alert on deviations
• Monitor process arguments for vncserver instances to verify -rfbport -1 is present when using TigerVNC
• Implement periodic security scans for open VNC ports on JupyterHub infrastructure

How to Mitigate CVE-2025-32428

Immediate Actions Required

• Upgrade jupyter-remote-desktop-proxy to version 3.0.1 or later immediately
• Audit current JupyterHub deployments to identify systems using TigerVNC as the VNC server
• Implement network segmentation to restrict VNC traffic until patches are applied
• Consider temporarily switching to TurboVNC as the vncserver executable if immediate patching is not possible

Patch Information

The vulnerability has been addressed in jupyter-remote-desktop-proxy version 3.0.1. The fix introduces automatic detection of the VNC server type (TigerVNC vs TurboVNC) and applies the appropriate command-line arguments to ensure TCP port binding is disabled. Users should update to version 3.0.1 or later using their package manager:

For detailed patch information, refer to the GitHub Security Advisory and the GitHub Commit.

Workarounds

• Switch from TigerVNC to TurboVNC as the vncserver executable, which is not affected by this vulnerability
• Manually add -rfbport -1 to TigerVNC startup arguments in custom configurations
• Implement firewall rules to block VNC traffic (ports 5900-5999) at the network level until patching is complete
• Use network policies in containerized environments to restrict VNC port exposure

# Verify if your system is using TigerVNC or TurboVNC
which vncserver
grep -i "turbovnc\|tigervnc" $(which vncserver)

# Check for exposed VNC ports
ss -tlnp | grep -E "590[0-9]"

# Update jupyter-remote-desktop-proxy
pip install --upgrade jupyter-remote-desktop-proxy>=3.0.1

# Firewall rule to block VNC ports temporarily (example for iptables)
iptables -A INPUT -p tcp --dport 5900:5999 -j DROP