Summary

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.

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.

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.