CVE-2026-33175: 
Python vulnerability analysis and mitigation

CVE-2026-33175 is an authentication bypass vulnerability in JupyterHub's oauthenticator library, specifically affecting the Auth0OAuthenticator component. It allows an attacker with an unverified email address on an Auth0 tenant to log in to JupyterHub, and when email is used as the username_claim, enables full account takeover of existing users. All versions of oauthenticator up to and including 17.3.1 are affected; version 17.4.0 contains the fix. The vulnerability was published on April 3, 2026, with a CVSS v3.1 base score of 8.8 (High) (Github Advisory, GitHub Security Advisory).

The root cause is that Auth0OAuthenticator did not verify the email_verified flag from Auth0's userinfo endpoint before accepting an email claim as a valid username (CWE-287: Improper Authentication; CWE-290: Authentication Bypass by Spoofing). By default, Auth0 treats email verification as a user attribute flag rather than a hard block on authentication flows, meaning a user with an unverified email can still complete the OAuth flow. The fix, introduced in commit f0c7002, adds a check_allowed override that raises an HTTP 403 error if email_verified is not True, unless the new allow_unverified_email configuration option is explicitly set to True (GitHub Commit, Github Advisory). Exploitation requires the attacker to have low-level privileges (the ability to register an account on the Auth0 tenant) and knowledge of a target user's email address.

Successful exploitation allows an attacker to authenticate to JupyterHub as an arbitrary existing user whose email address they know, resulting in full account takeover with high impacts on confidentiality, integrity, and availability. The attacker gains access to the victim's notebooks, data, compute resources, and any secrets or credentials stored within the JupyterHub environment. In multi-user research or enterprise deployments, this could expose sensitive datasets, proprietary code, or enable lateral movement to connected infrastructure (Github Advisory, GitHub Security Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.098–0.148%, placing it in the 35th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify a JupyterHub instance configured to use Auth0OAuthenticator with username_claim set to email. Enumerate or guess the email address of an existing JupyterHub user (e.g., via public profiles, organizational directories, or prior data exposure).
2. Register an Auth0 account: On the target Auth0 tenant (which must allow self-registration), create a new account using the victim's email address. Do not complete the email verification step — leave the email unverified.
3. Initiate OAuth login: Navigate to the JupyterHub login page and initiate the Auth0 OAuth flow. Authenticate using the newly created Auth0 account with the unverified email.
4. Bypass email verification check: Because vulnerable versions of Auth0OAuthenticator (≤ 17.3.1) do not check the email_verified flag, the OAuth flow completes successfully and JupyterHub maps the unverified email to the victim's username.
5. Account takeover: The attacker is now logged in as the victim user, gaining full access to their JupyterHub environment, notebooks, data, and any stored credentials (GitHub Security Advisory, Github Advisory).

• Logs: JupyterHub server logs showing successful logins for users whose email addresses were not previously active, or login events from unexpected IP addresses for known accounts; Auth0 audit logs showing new account registrations with unverified emails followed immediately by JupyterHub login events.
• Auth0 Logs: Auth0 tenant logs (/api/v2/logs) showing ss (success signup) events for email addresses matching existing JupyterHub users, where email_verified is false, followed by s (success login) events.
• JupyterHub: Unexpected new user sessions or notebook activity for accounts that have not recently been active; duplicate or near-duplicate user entries in JupyterHub's user database differing only by session origin.
• Network: OAuth callback requests to JupyterHub's /hub/oauth_callback endpoint originating from unfamiliar IP addresses or geolocations for established user accounts.

Upgrade oauthenticator to version 17.4.0 or later, which enforces email_verified checks in Auth0OAuthenticator.check_allowed() by default (GitHub Release, GitHub Commit). If immediate upgrade is not possible, apply one or more of the following workarounds:

• Implement a post_auth_hook function in your Authenticator configuration that checks the email_verified field and rejects logins where it is False.
• Change the username_claim configuration away from email to a claim that cannot be self-assigned (e.g., sub).
• Enforce email verification at the Auth0 tenant level to block unverified users from completing authentication flows (Github Advisory).

The vulnerability was reported by security researchers Jaynornj and Pr00fOf3xpl0it and published by JupyterHub maintainer minrk on April 2–3, 2026 (GitHub Security Advisory). Coverage appeared on The Hacker Wire and was tracked by ENISA's EUVD and Red Hat's security advisory database shortly after disclosure. No significant controversy or widespread community debate has been noted beyond standard patch-urgency messaging.