CVE-2024-41942: Jupyter JupyterHub Privilege Escalation

CVE-2024-41942 Overview

CVE-2024-41942 is a privilege escalation vulnerability in JupyterHub, the multi-user server for Jupyter notebooks. Users granted the admin:users scope can escalate their own privileges by making themselves a full built-in JupyterHub admin. The admin:users scope was intended to allow user management without conveying unrestricted admin=True status, but the API did not enforce that separation. The issue affects JupyterHub versions prior to 4.1.6 and 5.1.0. It maps to [CWE-274: Improper Handling of Insufficient Privileges].

Critical Impact
A user holding the admin:users scope can promote themselves to full JupyterHub admin, gaining unrestricted platform permissions beyond the scope's intended boundary.

Affected Products

JupyterHub versions prior to 4.1.6
JupyterHub 5.0.0 (including beta1 and beta2) prior to 5.1.0
Deployments granting the admin:users scope to non-admin roles

Discovery Timeline

2024-08-08 - CVE-2024-41942 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-41942

Vulnerability Analysis

JupyterHub uses a scope-based permission model where individual capabilities are granted to roles. The admin:users scope is documented as permission to read, write, create, and delete users and their authentication state. It is not intended to grant the built-in admin=True flag, which conveys unrestricted platform permissions.

The user API endpoint accepted an admin field in create and modify requests without verifying that the caller already held admin status. A user with only the admin:users scope could therefore submit a request setting admin: true on their own account or another account. This made admin:users effectively equivalent to admin=True, contradicting the documented scope boundary.

The fix does not restrict group-based permission grants. Users with the groups scope can still assign permissions via group membership, which is intentional behavior.

Root Cause

The root cause is missing authorization enforcement in the users API handler. The handler read the admin field from the request body but did not check whether the current user held the built-in admin role before applying the change. This is a privilege boundary flaw between a delegated scope and the superuser role.

Attack Vector

Exploitation requires network access to the JupyterHub API and an account already holding the admin:users scope. The attacker sends an authenticated API request to create or modify a user with admin: true in the payload. The server accepts the request and promotes the target account to full admin.

python

# Patch: jupyterhub/apihandlers/users.py
# admin is set for all users
# to create admin and non-admin users requires at least two API requests
admin = data.get('admin', False)
if admin and not self.current_user.admin:
    raise web.HTTPError(403, "Only admins can grant admin permissions")

to_create = []
invalid_names = []
# Source: https://github.com/jupyterhub/jupyterhub/commit/99e2720b0fc626cbeeca3c6337f917fdacfaa428

The patch adds an explicit check that rejects any request setting admin=True unless the calling user is already a built-in admin. A companion change in jupyterhub/scopes.py updates the admin:users scope documentation to clarify that it is tantamount to superuser and should be granted with equivalent caution.

Detection Methods for CVE-2024-41942

Indicators of Compromise

JupyterHub API POST or PATCH requests to /hub/api/users or /hub/api/users/{name} containing "admin": true in the body from non-admin service accounts or users.
Audit log entries showing a user account transitioning to admin=True without a corresponding action by an existing built-in admin.
Unexpected new admin accounts created shortly after admin:users scope grants.

Detection Strategies

Enable JupyterHub request logging and inspect API traffic for payloads that set the admin flag.
Query the JupyterHub database (users table) for accounts where admin=1 and correlate creation or modification timestamps with API access logs.
Alert on privilege changes performed by users whose roles include admin:users but not the built-in admin role.

Monitoring Recommendations

Forward JupyterHub application and web server logs to a centralized log platform and retain them for privilege-change forensics.
Baseline the expected set of built-in admin accounts and alert on additions.
Monitor role and scope assignments in the JupyterHub configuration for grants of admin:users to shared or service identities.

How to Mitigate CVE-2024-41942

Immediate Actions Required

Upgrade JupyterHub to version 4.1.6 or 5.1.0 or later.
Audit all roles and users currently holding the admin:users scope and review the built-in admin user list for unexpected entries.
Revoke admin:users from any account that does not require full user management capability.

Patch Information

The vulnerability is fixed in JupyterHub 4.1.6 and 5.1.0. The corrective code is present in commit 99e2720 and commit ff2db55. See the JupyterHub Security Advisory GHSA-9x4q-3gxw-849f for full details.

Workarounds

Restrict the admin:users scope to accounts that are already trusted as built-in admins until the upgrade is applied.
Place JupyterHub behind an authenticating reverse proxy that can filter API request bodies containing "admin": true for non-admin identities.
Review and reduce custom roles that combine admin:users with lower-trust user populations.

bash

# Verify the running JupyterHub version and upgrade
jupyterhub --version
pip install --upgrade 'jupyterhub>=5.1.0'
# or, for the 4.x branch
pip install --upgrade 'jupyterhub>=4.1.6,<5'

# Restart the hub service
systemctl restart jupyterhub