An authentication bypass vulnerability in oauthenticator allows an attacker with an unverified email address on an Auth0 tenant to login to JupyterHub. When email is used as the usrname_claim, this gives users control over their username and the possibility of account takeover.
JupyterHub < 5.0, when used with GlobusOAuthenticator, could be configured to allow all users from a particular institution only. The configuration for this would look like:
[GoogleOAuthenticator.hosted_domain] is used to restrict what Google accounts can be authorized to access a JupyterHub. The restriction is intended to ensure Google accounts are part of one or more Google organizations/workspaces verified to control specified domain(s). The vulnerability is that the actual restriction has been to Google accounts with emails ending with the domain. Such accounts could have been created by anyone which at one time was able to read …
OAuthenticator is an OAuth token library for the JupyerHub login handler. CILogonOAuthenticator is provided by the OAuthenticator package, and lets users log in to a JupyterHub via CILogon. This is primarily used to restrict a JupyterHub only to users of a given institute. The allowed_idps configuration trait of CILogonOAuthenticator is documented to be a list of domains that indicate the institutions whose users are authorized to access this JupyterHub. This …
This advisory duplicates another.
An issue was discovered in Project Jupyter JupyterHub OAuthenticator. When using JupyterHub with a GitLab allowlist for access control, group membership is not checked correctly, allowing members that are not in the allowlist to create accounts on the Hub.
In oauthenticator, the deprecated (in jupyterhub ) configuration Authenticator.whitelist, which should be transparently mapped to Authenticator.allowed_users with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set.