GHSA-gprj-3p75-f996
HIGHGlobus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
oauthenticatorReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | oauthenticator | all versions | 16.3.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for oauthenticator. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update oauthenticator to 16.3.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gprj-3p75-f996 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gprj-3p75-f996 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gprj-3p75-f996. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gprj-3p75-f996 in your dependencies?
O3 detects GHSA-gprj-3p75-f996 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.