CVSS: 7.2EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41942 – JupyterHub has a privilege escalation vulnerability with the `admin:users` scope
https://notcve.org/view.php?id=CVE-2024-41942
JupyterHub is software that allows one to create a multi-user server for Jupyter notebooks. Prior to versions 4.1.6 and 5.1.0, if a user is granted the `admin:users` scope, they may escalate their own privileges by making themselves a full admin user. 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. • https://github.com/jupyterhub/jupyterhub/commit/99e2720b0fc626cbeeca3c6337f917fdacfaa428 https://github.com/jupyterhub/jupyterhub/commit/ff2db557a85b6980f90c3158634bf924063ab8ba https://github.com/jupyterhub/jupyterhub/security/advisories/GHSA-9x4q-3gxw-849f • CWE-274: Improper Handling of Insufficient Privileges •
CVSS: 8.1EPSS: 0%CPEs: 1EXPL: 0CVE-2024-37300 – Globus `identity_provider` restriction ignored when used with `allow_all` in JupyterHub 5.0
https://notcve.org/view.php?id=CVE-2024-37300
OAuthenticator is software that allows OAuth2 identity providers to be plugged in and used with JupyterHub. JupyterHub < 5.0, when used with `GlobusOAuthenticator`, could be configured to allow all users from a particular institution only. 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`. • https://github.com/jupyterhub/oauthenticator/commit/d1aea05fa89f2beae15ab0fa0b0d071030f79654 https://github.com/jupyterhub/oauthenticator/security/advisories/GHSA-gprj-3p75-f996 https://jupyterhub.readthedocs.io/en/stable/howto/upgrading-v5.html#authenticator-allow-all-and-allow-existing-users • CWE-863: Incorrect Authorization •
CVSS: 9.6EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35225 – Jupyter Server Proxy has a reflected XSS issue in host parameter
https://notcve.org/view.php?id=CVE-2024-35225
Jupyter Server Proxy allows users to run arbitrary external processes alongside their notebook server and provide authenticated web access to them. Versions of 3.x prior to 3.2.4 and 4.x prior to 4.2.0 have a reflected cross-site scripting (XSS) issue. The `/proxy` endpoint accepts a `host` path segment in the format `/proxy/<host>`. When this endpoint is called with an invalid `host` value, `jupyter-server-proxy` replies with a response that includes the value of `host`, without sanitization [2]. A third-party actor can leverage this by sending a phishing link with an invalid `host` value containing custom JavaScript to a user. • https://github.com/jupyterhub/jupyter-server-proxy/blob/62a290f08750f7ae55a0c29ca339c9a39a7b2a7b/jupyter_server_proxy/handlers.py#L328 https://github.com/jupyterhub/jupyter-server-proxy/commit/7abc9dc5bbb0b4b440548a5375261b8b8192fc22 https://github.com/jupyterhub/jupyter-server-proxy/commit/ff78128087e73fb9d0909e1366f8bf051e8ea878 https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-fvcq-4x64-hqxr • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CWE-116: Improper Encoding or Escaping of Output •
CVSS: 8.1EPSS: 0%CPEs: 1EXPL: 0CVE-2024-28233 – XSS in JupyterHub via Self-XSS leveraged by Cookie Tossing
https://notcve.org/view.php?id=CVE-2024-28233
JupyterHub is an open source multi-user server for Jupyter notebooks. 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 full access to JupyterHub API and user's single-user server. The affected configurations are single-origin JupyterHub deployments and JupyterHub deployments with user-controlled applications running on subdomains or peer subdomains of either the Hub or a single-user server. This vulnerability is fixed in 4.1.0. • https://github.com/jupyterhub/jupyterhub/commit/e2798a088f5ad45340fe79cdf1386198e664f77f https://github.com/jupyterhub/jupyterhub/security/advisories/GHSA-7r3h-4ph8-w38g • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CWE-352: Cross-Site Request Forgery (CSRF) CWE-565: Reliance on Cookies without Validation and Integrity Checking •
CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2024-29033 – GoogleOAuthenticator.hosted_domain incorrectly verifies membership of an Google organization/workspace
https://notcve.org/view.php?id=CVE-2024-29033
OAuthenticator provides plugins for JupyterHub to use common OAuth providers, as well as base classes for writing one's own Authenticators with any OAuth 2.0 provider. `GoogleOAuthenticator.hosted_domain` is used to restrict what Google accounts can be authorized access to a JupyterHub. The restriction is intented to be to Google accounts part of one or more Google organization verified to control specified domain(s). Prior to version 16.3.0, the actual restriction has been to Google accounts with emails ending with the domain. Such accounts could have been created by anyone which at one time was able to read an email associated with the domain. • https://github.com/jupyterhub/oauthenticator/commit/5246b09675501b09fb6ed64022099b7644812f60 https://github.com/jupyterhub/oauthenticator/security/advisories/GHSA-55m3-44xf-hg4h https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of • CWE-285: Improper Authorization •