CVE-2024-37300
Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. JupyterHub < 5.0, when used with GlobusOAuthenticator, could be configured to allow all users from a particular institution only. 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. As a workaround, do not upgrade to JupyterHub 5.0 when using GlobusOAuthenticator in the prior configuration.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- Low
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. JupyterHub < 5.0, when used with GlobusOAuthenticator, could be configured to allow all users from a particular institution only. 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. As a workaround, do not upgrade to JupyterHub 5.0 when using GlobusOAuthenticator in the prior configuration.
- Record
CVE-2024-37300- CVSS 3.1
- 8.1 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
EUVDEUVD-2024-2058
OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. JupyterHub < 5.0, when used with GlobusOAuthenticator, could be configured to allow all users from a particular institution only. 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. As a workaround, do not upgrade to JupyterHub 5.0 when using GlobusOAuthenticator in the prior configuration.
- Record
EUVD-2024-2058- CVSS 3.1
- 8.1 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-03
GitHub AdvisoriesGHSA-gprj-3p75-f996
Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
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:
# 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.
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.
- Record
GHSA-gprj-3p75-f996- CVSS 3.1
- 8.1 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
NVD
OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. JupyterHub < 5.0, when used with GlobusOAuthenticator, could be configured to allow all users from a particular institution only. 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. As a workaround, do not upgrade to JupyterHub 5.0 when using GlobusOAuthenticator in the prior configuration.
- Record
CVE-2024-37300- CVSS 3.1
- 8.1 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
OSV
Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. JupyterHub < 5.0, when used with GlobusOAuthenticator, could be configured to allow all users from a particular institution only. 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. As a workaround, do not upgrade to JupyterHub 5.0 when using GlobusOAuthenticator in the prior configuration.
- Record
CVE-2024-37300- CVSS 3.1
- 8.1 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
OSVGHSA-gprj-3p75-f996
Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
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:
# 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.
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.
- Record
GHSA-gprj-3p75-f996- CVSS 3.1
- 8.1 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-863
- Updated
- 2026-11-02
OSVPYSEC-2026-1711
Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
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:
# 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.
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.
- Record
PYSEC-2026-1711- CVSS 3.1
- 8.1 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
oauthenticatorPyPI |
before 16.3.1 | 16.3.1 |
oauthenticatorPyPI |
before 16.3.1, plus listed versions 0.1.00.10.00.11.00.12.00.12.1 Show 39 moreShow less0.12.20.12.30.13.00.2.00.3.00.4.00.4.10.5.00.5.10.6.00.6.10.6.20.7.00.7.10.7.20.7.30.8.00.8.10.8.20.9.014.0.014.1.014.2.015.0.015.0.115.1.016.0.016.0.116.0.216.0.316.0.416.0.516.0.616.0.716.1.016.1.116.2.016.2.116.3.0 |
16.3.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| aliases, published | EUVD | |
| first indexed | CVE List, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2024-37300 is a high vulnerability (CVSS 8.1) in Jupyterhub Oauthenticator, published June 12, 2024. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.40%, the 34th percentile. Fixed in oauthenticator 16.3.1.
References
github.com/jupyterhub/oauthenticator/security/advisories/GHSA-gprj-3p75-f996
jupyterhub.readthedocs.io/en/stable/howto/upgrading-v5.html
nvd.nist.gov/vuln/detail/CVE-2024-37300
pypi.org/project/oauthenticator