CVE-2024-41942

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 themselves or other users permissions via group membership, which is intentional. Versions 4.1.6 and 5.1.0 fix this issue.

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 themselves or other users permissions via group membership, which is intentional. Versions 4.1.6 and 5.1.0 fix this issue.

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 themselves or other users permissions via group membership, which is intentional. Versions 4.1.6 and 5.1.0 fix this issue.

### 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.

JupyterHub es un software que permite crear un servidor multiusuario para portátiles Jupyter. Antes de las versiones 4.1.6 y 5.1.0, si a un usuario se le otorgaba el alcance `admin:users`, podía escalar sus propios privilegios convirtiéndose en un usuario administrador completo. El impacto es relativamente pequeño en el sentido de que "admin:users" ya es un ámbito extremadamente privilegiado que solo se otorga a usuarios confiables. En efecto, `admin:users` es equivalente a `admin=True`, lo cual no es lo previsto. Tenga en cuenta que el cambio aquí solo evita la escalada al rol de administrador integrado de JupyterHub que tiene permisos sin restricciones. No impide que los usuarios con, por ejemplo, permisos de "grupos" se otorguen permisos a sí mismos o a otros usuarios a través de la membresía en un grupo, lo cual es intencional. Las versiones 4.1.6 y 5.1.0 solucionan este problema.