jupyterhub vulnerabilities

JupyterHub through 6.0.1 OAuth Client ID Collision via Unescaped Hyphen

JupyterHub through 6.0.1 contains an identifier collision vulnerability that allows authenticated users to overwrite another user's named-server OAuth client by registering a hyphenated username. Attackers holding a name like alice-prod can overwrite the client for alice's server prod, breaking OAuth login and revoking tokens by stopping their own server.

JupyterHub: Unauthenticated Denial of Service via Unbounded Username Logging on Failed Login

JupyterHub is software that allows users to create a multi-user server for Jupyter notebooks. Prior to 5.5.0, invalid input to form-based login authenticators can place an unbounded attacker-controlled username in failed-login logs, allowing an unauthenticated attacker to consume logging and storage resources. This issue is fixed in version 5.5.0.

JupyterHub: Cross-origin form POSTs bypass XSRF

JupyterHub is software that allows users to create a multi-user server for Jupyter notebooks. In versions 4.1.0 through 5.4.4, XSRF protection (updated in 4.1.0) inappropriately treated requests with Sec-Fetch-Mode: no-cors as same-origin requests, bypassing XSRF checks. The JSON API is not affected, only HTTP form endpoints, such as /hub/spawn and /hub/accept-share, meaning attackers could trigger server spawn (but not access the server) and if the attacker is a JupyterHub user permitted to share access to their server, cause a user to accept a share and have access to the attacker's server. This issue has been fixed in version 5.4.5. If dev

JupyterHub has an Open Redirect Vulnerability

JupyterHub is software that allows one to create a multi-user server for Jupyter notebooks. Prior to version 5.4.4, an open redirect vulnerability in JupyterHub allows attackers to construct links which, when clicked, take users to the JupyterHub login page, after which they are sent to an arbitrary attacker-controlled site outside JupyterHub instead of a JupyterHub page, bypassing JupyterHub's check to prevent this. This issue has been patched in version 5.4.4.

JupyterHub has a privilege escalation vulnerability with the `admin:users` scope

JupyterHub is software that allows one to create a multi-user server for Jupyter notebooks. Prior to versions 4.1.6 and 5.1.0, if a user is granted the `admin:users` scope, they may escalate their own privileges by making themselves a full admin user. The impact is relatively small in that `admin:users` is already an extremely privileged scope only granted to trusted users. In effect, `admin:users` is equivalent to `admin=True`, which is not intended. Note that the change here only prevents escalation to the built-in JupyterHub admin role that has unrestricted permissions. It does not prevent users with e.g. `groups` permissions from granting

• Update to 5.2.1+ds1-1

XSS in JupyterHub via Self-XSS leveraged by Cookie Tossing

JupyterHub is an open source multi-user server for Jupyter notebooks. By tricking a user into visiting a malicious subdomain, the attacker can achieve an XSS directly affecting the former's session. More precisely, in the context of JupyterHub, this XSS could achieve full access to JupyterHub API and user's single-user server. The affected configurations are single-origin JupyterHub deployments and JupyterHub deployments with user-controlled applications running on subdomains or peer subdomains of either the Hub or a single-user server. This vulnerability is fixed in 4.1.0.

• Update to 5.0.0+ds1-1

incomplete logout in JupyterHub

JupyterHub is an open source multi-user server for Jupyter notebooks. In affected versions users who have multiple JupyterLab tabs open in the same browser session, may see incomplete logout from the single-user server, as fresh credentials (for the single-user server only, not the Hub) reinstated after logout, if another active JupyterLab session is open while the logout takes place. Upgrade to JupyterHub 1.5. For distributed deployments, it is jupyterhub in the _user_ environment that needs patching. There are no patches necessary in the Hub environment. The only workaround is to make sure that only one JupyterLab tab is open when you log o

• Update to 2.0.0+ds1-1

CVE-2020-36191

JupyterHub 1.1.0 allows CSRF in the admin panel via a request that lacks an _xsrf field, as demonstrated by a /hub/api/user request (to add or remove a user account).

• Update to 3.0.0+ds1-1