JupyterHub is software that allows users to create a multi-user server for Jupyter notebooks. In versions 4.1.0 through 5.4.4, XSRF protection (updated in 4.1.0) inappropriately treated requests with Sec-Fetch-Mode: no-cors as same-origin requests, 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. This issue has been fixed in version 5.4.5. If developers are unable to immediately upgrade, they can temporarily mitigate this issue by dropping requests to JupyterHub with Sec-Fetch-Mode: no-cors if they are using a reverse proxy.

In udev in systemd before 260, local root execution can occur via malicious hardware devices and unsanitized kernel output.

In nspawn in systemd 233 through 259 before 260, an escape-to-host action can occur via a crafted optional config file.

In systemd 260 before 261, a local unprivileged user can trigger an assert via an IPC API call with an array or map that has a null element.

In systemd 259 before 260, there is local privilege escalation in systemd-machined because varlink can be used to reach the root namespace.

In systemd 259, systemd-journald can send ANSI escape sequences to the terminals of arbitrary users when a "logger -p emerg" command is executed, if ForwardToWall=yes is set.