Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 usrnameclaim, this gives users control over their username and the possibility of account takeover. Impact This is an Authentication Bypass Vulnerability. Any Auth0 tenant leveraging the Auth0OAuthenticator mapping the email claim to the JupyterHub username is impacted. By default, Auth0 handles email verification as a user flag, not a hard block to authentication streams. If an attacker can register an account with the Auth0 tenant with an unverified email and knows the email of an existing user on the system, they can authenticate as that user. Patches - Upgrade oauthenticator to 17.4 Workarounds - Check emailverified field in an Authenticator.postauthhook function - Do not use email as the username claim - Enforce email verification in auth0
Recommended action: Upgrade to 17.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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: This worked fine prior to JupyterHub 5.0, because allowall did not take precedence over identityprovider. Since JupyterHub 5.0, allowall does take precedence over identityprovider. On a hub with the same config, now all users will be allowed to login, regardless of identityprovider. identityprovider will basically be ignored. This is a documented change in JupyterHub 5.0, but is likely to catch many users by surprise. Patches OAuthenticator 16.3.1 fixes the issue with JupyterHub 5.0, and does not affect previous versions. Workarounds Do not upgrade to JupyterHub 5.0 when using GlobusOAuthenticator in the prior configuration.
Recommended action: Upgrade to 16.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
and impact [GoogleOAuthenticator.hosteddomain] 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 an email associated with the domain. This was described by Dylan Ayrey (@dxa4481) in this [blog post] from 15th December 2023. Remediation Upgrade to oauthenticator=16.3.0 or restrict who can login another way, such as [allowedusers] or [allowedgooglegroups]. [GoogleOAuthenticator.hosteddomain]: https://oauthenticator.readthedocs.io/en/latest/reference/api/gen/oauthenticator.google.html#oauthenticator.google.GoogleOAuthenticator.hosteddomain [allowedusers]:…
Recommended action: Upgrade to 16.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Background CILogon is a federated auth provider that allows users to authenticate themselves via a number of Identity Providers (IdP), focused primarily on educational and research institutions (such as Universities). More traditional and open IdPs such as GitHub, ORCID, Google, Microsoft, etc are also supported. 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 allowedidps 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 authorization is validated by ensuring that the email field provided to us by CILogon has a domain that matches one of the domains listed in allowedidps. Impact If allowedidps contains berkeley.edu, you might expect only users with valid current credentials provided by University of…
Recommended action: Upgrade to 15.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Project Jupyter JupyterHub OAuthenticator 0.6.x before 0.6.2 and 0.7.x before 0.7.3. When using JupyterHub with GitLab group whitelisting for access control, group membership was not checked correctly, allowing members not in the whitelisted groups to create accounts on the Hub. (Users were not allowed to access other users' accounts, but could create their own accounts on the Hub linked to their GitLab account. GitLab authentication not using gitlabgroupwhitelist is unaffected. No other Authenticators are affected.)
Recommended action: Upgrade to 0.7.3 or 0.6.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What goes wrong? The deprecated (in jupyterhub 1.2) configuration Authenticator.whitelist, which should be transparently mapped to Authenticator.allowedusers with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set. If this is the only mechanism of authorization restriction (i.e. no group or team restrictions in configuration) then all authenticated users will be allowed. Provider-based restrictions, including deprecated values such as GitHubOAuthenticator.orgwhitelist are not affected. Who is impacted? All users of OAuthenticator 0.12.0 and 0.12.1 with JupyterHub 1.2 (JupyterHub Helm chart 0.10.0-0.10.5) who use the admin.whitelist.users configuration in the jupyterhub helm chart or the c.Authenticator.whitelist configuration directly. Users of other deprecated configuration, e.g. c.GitHubOAuthenticator.teamwhitelist are not affected. If you see a log line like this and expect a specific list of…
Recommended action: Upgrade to 0.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.