Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact There is a reflected cross-site scripting (XSS) issue in jupyter-server-proxy[1]. The /proxy endpoint accepts a host path segment in the format /proxy/<host. When this endpoint is called with an invalid host value, jupyter-server-proxy replies with a response that includes the value of host, without sanitization [2]. A third-party actor can leverage this by sending a phishing link with an invalid host value containing custom JavaScript to a user. When the user clicks this phishing link, the browser renders the response of GET /proxy/<host, which runs the custom JavaScript contained in host set by the actor. As any arbitrary JavaScript can be run after the user clicks on a phishing link, this issue permits extensive access to the user's JupyterLab instance for an actor. This issue exists in the latest release of jupyter-server-proxy, currently v4.1.2. Impacted versions: =3.0.0,<=4.1.2 Patches The patches are included in ==4.2.0 and ==3.2.4. Workarounds Server operators who are…
Recommended action: Upgrade to 4.2.0 or 3.2.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
jupyter-server-proxy is used to expose ports local to a Jupyter server listening to web traffic to the Jupyter server's authenticated users by proxying web requests and websockets. Dependent packages (partial list) also use jupyter-server-proxy to expose other popular interactive applications (such as RStudio, Linux Desktop via VNC, Code Server, Panel, etc) along with the Jupyter server. This feature is commonly used in hosted environments (such as a JupyterHub) to expose non-Jupyter interactive frontends or APIs to the user. jupyter-server-proxy did not check user authentication appropriately when proxying websockets, allowing unauthenticated access to anyone who had network access to the Jupyter server endpoint. Impact This vulnerability can allow unauthenticated remote access to any websocket endpoint set up to be accessible via jupyter-server-proxy. In many cases (such as when exposing RStudio via jupyter-rsession-proxy or a remote Linux Desktop / VNC via…
Recommended action: Upgrade to 4.1.1 or 3.2.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Server-Side Request Forgery ( SSRF ) Who is impacted? Any user deploying Jupyter Server or Notebook with jupyter-proxy-server extension enabled. A lack of input validation allowed authenticated clients to proxy requests to other hosts, bypassing the allowedhosts check. Because authentication is required, which already grants permissions to make the same requests via kernel or terminal execution, this is considered low to moderate severity. Patches Has the problem been patched? What versions should users upgrade to? Upgrade to 3.2.1, or apply the patch https://github.com/jupyterhub/jupyter-server-proxy/compare/v3.2.0...v3.2.1.patch For more information If you have any questions or comments about this advisory: Open a topic on our forum Email the Jupyter security team at security@ipython.org
Recommended action: Upgrade to 3.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.