Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Invalid input to login resulted in unbounded logging output. Only form-based Authenticators (the default PAM Authenticator, but not the more widely used OAuthenticator) are affected. Patches Upgrade to 5.5.0. Workarounds Use an Authenticator that doesn't use a login form, such as OAuthenticator.
Recommended action: Upgrade to 5.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterHub's XSRF protection (updated in 4.1.0) inappropriately treated requests with Sec-Fetch-Mode: no-cors as same-origin requests, which they are not, bypassing XSRF checks. The JSON API is not affected, only HTTP form endpoints, such as /hub/spawn and /hub/accept-share, meaning attackers could trigger server spawn (but not access the server) and if the attacker is a JupyterHub user permitted to share access to their server, cause a user to accept a share and have access to the attacker's server. Patches Upgrade to JupyterHub 5.4.5. Mitigations If a reverse proxy is in use, drop requests to JupyterHub with Sec-Fetch-Mode: no-cors.
Recommended action: Upgrade to 5.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected Version JupyterHub <= 5.4.3 Impact An open redirect vulnerability in JupyterHub <=5.4.3 allows attackers to construct links which, when clicked, take users to the JupyterHub login page, after which they are sent to an arbitrary attacker-controlled site outside JupyterHub instead of a JupyterHub page, bypassing JupyterHub's check to prevent this. Patches Upgrade to JupyterHub 5.4.4 Workarounds A deployment can apply filters on the Location header in a reverse proxy such as nginx/apache/traefik.
Recommended action: Upgrade to 5.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If a user is granted the admin:users scope, they may escalate their own privileges by making themselves a full admin user. Details The admin:users scope allows a user to edit user records: admin:users Read, write, create and delete users and their authentication state, not including their servers or tokens. -- https://jupyterhub.readthedocs.io/en/stable/rbac/scopes.html#available-scopes However, this includes making users admins. Admin users are granted scopes beyond admin:users making this a mechanism by which granted scopes may be escalated. Impact The impact is relatively small in that admin:users is already an extremely privileged scope only granted to trusted users. In effect, admin:users is equivalent to admin=True, which is not intended. Note that the change here only prevents escalation to the built-in JupyterHub admin role that has unrestricted permissions. It does not prevent users with e.g. groups permissions from granting themselves or other users permissions via…
Recommended action: Upgrade to 5.1.0 or 4.1.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Affected configurations: - Single-origin JupyterHub deployments - JupyterHub deployments with user-controlled applications running on subdomains or peer subdomains of either the Hub or a single-user server. By tricking a user into visiting a malicious subdomain, the attacker can achieve an XSS directly affecting the former's session. More precisely, in the context of JupyterHub, this XSS could achieve the following: - Full access to JupyterHub API and user's single-user server, e.g. - Create and exfiltrate an API Token - Exfiltrate all files hosted on the user's single-user server: notebooks, images, etc. - Install malicious extensions. They can be used as a backdoor to silently regain access to victim's session anytime. Patches To prevent cookie-tossing: - Upgrade to JupyterHub 4.1 (both hub and user environment) - enable per-user domains via c.JupyterHub.subdomainhost = "https://mydomain.example.org" - set c.JupyterHub.cookiehostprefixenabled = True to enable domain-locked…
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterHub 1.1.0 allows CSRF in the admin panel via a request that lacks an xsrf field, as demonstrated by a /hub/api/user request (to add or remove a user account).
Recommended action: Upgrade to 1.2.0b1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users of JupyterLab with JupyterHub who have multiple JupyterLab tabs open in the same browser session, may see incomplete logout from the single-user server, as fresh credentials (for the single-user server only, not the Hub) reinstated after logout, if another active JupyterLab session is open while the logout takes place. Patches Upgrade to JupyterHub 1.5. For distributed deployments, it is jupyterhub in the user environment that needs patching. There are no patches necessary in the Hub environment. Workarounds The only workaround is to make sure that only one JupyterLab tab is open when you log out.
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An Open Redirect vulnerability for all browsers in Jupyter Notebook before 5.7.8 and some browsers (Chrome, Firefox) in JupyterHub before 0.9.6 allows crafted links to the login page, which will redirect to a malicious site after successful login. Servers running on a baseurl prefix are not affected.
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.