CVE-2022-31027
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedOAuthenticator 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 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 `allowed_idps`.If `allowed_idps` contains `berkeley.edu`, you might expect only users with valid current credentials provided by University of California, Berkeley to be able to access the JupyterHub. However, CILogonOAuthenticator does *not* verify which provider is used by the user to login, only the email address provided. So a user can login with a GitHub account that has email set to `<something>@berkeley.edu`, and that will be treated exactly the same as someone logging in using the UC Berkeley official Identity Provider. The patch fixing this issue makes a *breaking change* in how `allowed_idps` is interpreted. It's no longer a list of domains, but configuration representing the `EntityID` of the IdPs that are allowed, picked from the [list maintained by CILogon](https://cilogon.org/idplist/). Users are advised to upgrade.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceCILogonOAuthenticator for JupyterHub only validates the email domain from user claims rather than verifying the actual Identity Provider used during login. This allows attackers to bypass allowed_idps restrictions by authenticating through external providers (e.g., GitHub) with email addresses matching the configured domain (e.g., [email protected]).
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data< 15.0.0CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Check installed Jupyter Oauthenticator versionRun 'pip show oauthenticator' or check your package manager to see the installed version numberAffected if Version is below 15.0.0 (e.g., 14.x.x, 13.x.x, etc.)
-
Identify CILogonOAuthenticator configurationReview your JupyterHub configuration file (typically jupyterhub_config.py) for any instances of CILogonOAuthenticator or the setting 'c.CILogonOAuthenticator'Affected if CILogonOAuthenticator is configured and in use
-
Locate allowed_idps configurationSearch the JupyterHub config for 'allowed_idps' or 'allow_all' settings under the CILogon authenticator sectionAffected if allowed_idps is configured using domain-based values (e.g., entries where the key looks like an email domain such as 'berkeley.edu' rather than an EntityID)
-
Verify email domain validation relianceCheck if the configuration relies on email domain matching alone to restrict login access, particularly without verifying the specific Identity Provider entity used during authenticationAffected if Login restrictions are based solely on email domain without EntityID verification
You are affected if Jupyter Oauthenticator is below version 15.0.0 and your CILogon configuration uses domain-based allowed_idps restrictions that rely only on email domain matching rather than verifying the actual Identity Provider EntityID.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped15.0.0
Upgrade to the patched OAuthenticator version and migrate allowed_idps configuration from domain-based to EntityID-based values from the CILogon IdP list; validate that login is now properly restricted to the intended institutional IdPs.
15.0.0
- Upgrade OAuthenticator to version 15.0.0 or later
- Review the CILogon IdP list at https://cilogon.org/idplist/ to identify the EntityID(s) for your allowed institution(s)
- Update your CILogonOAuthenticator configuration to replace domain-based allowed_idps entries with the corresponding EntityID values from the CILogon list
- Restart JupyterHub to apply the configuration changes
- Verify that only users authenticating through the configured IdP EntityID can access the JupyterHub
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation2.0 h
- Testing2.0 h
- Review / QA1.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $1,984.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2022-31027 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2022-31027 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data