CVE-2024-37300High· 8.1▾ TwilightGlobus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 44.6 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 8.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
0.4%
Last analysed / modified upstream
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:
# Require users to be using the "foo.horse" identity provider, often an institution or university
c.GlobusAuthenticator.identity_provider = "foo.horse"
# Allow everyone who has that identity provider to log in
c.GlobusAuthenticator.allow_all = True
This worked fine prior to JupyterHub 5.0, because allow_all did not take precedence over identity_provider.
Since JupyterHub 5.0, allow_all does take precedence over identity_provider. On a hub with the same config, now all users will be allowed to login, regardless of identity_provider. identity_provider will basically be ignored.
This is a documented change in JupyterHub 5.0, but is likely to catch many users by surprise.
OAuthenticator 16.3.1 fixes the issue with JupyterHub 5.0, and does not affect previous versions.
Do not upgrade to JupyterHub 5.0 when using GlobusOAuthenticator in the prior configuration.
oauthenticator < 16.3.1Upgrade to a patched release:
oauthenticator 16.3.1Connected by shared product, vendor, weakness, or advisory.
CVE-2026-33175High· 8.8Auth0OAuthenticator has an Authentication Bypass via Unverified Email Claims
CVE-2024-29033High· 7.5GoogleOAuthenticator.hosted_domain incorrectly verifies membership of an Google organization/workspace
CVE-2020-26250Medium· 6.3Base class whitelist configuration ignored in OAuthenticator