Impact
Due to an unsanitized input, visiting maliciously crafted links could result in arbitrary code execution in the user environment.
Patches
0.10.2
Workarounds
None, other than upgrade to 0.10.2 or downgrade to 0.8.x.
For more information
If you have any questions or comments about this advisory:
Open an issue in nbgitpuller Email our security team at security@ipython.org
Impact
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.
Patches
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.
Workarounds
The only workaround is to make sure that only one JupyterLab tab is open when you log out.
Summary
If a user is granted the admin:users scope, they may escalate their own privileges by making themselves a full admin user.
Details
The admin:users scope allows a user to edit user records:
admin:users Read, write, create and delete users and their authentication state, not including their servers or tokens. -- https://jupyterhub.readthedocs.io/en/stable/rbac/scopes.html#available-scopes
However, this includes making users admins. Admin users are granted scopes beyond admin:users making this a mechanism by which granted scopes may be escalated.
Impact
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 themselves or other users permissions via group membership, which is intentional.