Live › vulnerability › CVE-2025-32428
Go to dashboardjupyter-remote-desktop-proxy 3.0.0 was meant to expose the VNC server only over a UNIX socket readable by the current user, but with TigerVNC the VNC server still listens on the network. A network attacker who can reach that port can connect to the remote desktop session without going through Jupyter's authentication.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 17:27 UTC, 0h before NVD. All times on this page are UTC.
Teams running jupyter-remote-desktop-proxy 3.0.0 with TigerVNC as the vncserver executable, typically on shared or multi-user Jupyter hosts. Installations that use TurboVNC as vncserver are not affected according to the advisory, and the issue is only relevant if the VNC port is reachable from the network.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| jupyter-remote-desktop-proxy | pypi | = 3.0.0 | 3.0.1 |
pip show jupyter-remote-desktop-proxy and confirm the installed version is 3.0.0vncserver on the path is TigerVNC rather than TurboVNC, for example with vncserver -versionss -ltnp3.0.1Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
jupyter-remote-desktop-proxy was meant to rely on UNIX sockets readable only by the current user since version 3.0.0, but when used with TigerVNC, the VNC server started by jupyter-remote-desktop-proxy were still accessible via the network.
This vulnerability does not affect users having TurboVNC as the vncserver executable.
This vulnerability was identified by Arne Gottwald at University of Göttingen and analyzed, reported, and reviewed by @frejanordsiek.
This page as .md · .json · in your agent: get_signal("CVE-2025-32428")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.