JupyterHub has a privilege escalation vulnerability with the `admin:users` scope
If a user is granted the admin:users scope, they may escalate their own privileges by making themselves a full admin user.
If a user is granted the admin:users scope, they may escalate their own privileges by making themselves a full admin user.
Affected configurations: Single-origin JupyterHub deployments JupyterHub deployments with user-controlled applications running on subdomains or peer subdomains of either the Hub or a single-user server. 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 the following: Full access to JupyterHub API and user's single-user server, e.g. Create and exfiltrate …
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).
Users of JupyterLab with JupyterHub 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.
An Open Redirect vulnerability for all browsers in Jupyter Notebook before 5.7.7 and some browsers in JupyterHub before 0.9.5 allows crafted links to the login page, which will redirect to a malicious site after successful login. Servers running on a base_url prefix are not affected.