The vulnerability lies in insufficient input validation within Jupyter Enterprise Gateway's ContainerProcessProxy._enforce_prohibited_ids method. Jupyter Enterprise Gateway launches remote Jupyter Notebook kernels across distributed clusters such as Apache Spark, Kubernetes, and Docker Swarm. Versions 2.0.0rc1 through the 3.2.x releases prior to 3.3.0 disabled launching kernels with UID or GID 0 by default, but this restriction can be bypassed with a specially crafted KERNEL_UID or KERNEL_GID. An attacker can craft such values to launch a kernel as root inside the container. Running as root greatly expands the attack surface; the attacker can mount a hostPath read‑write volume, elevate to root within the container, and then create a crontab entry or otherwise execute code on the underlying worker node. This permits a full container escape that can compromise the worker node and all workloads on it, and repeated exploitation could bring down every node in a Kubernetes cluster. The issue was fixed in version 3.0.0.

Affected products are the Jupyter Enterprise Gateway component of jupyter‑server. Versions from 2.0.0rc1 through the 3.2.x releases prior to the 3.3.0 release contain the flawed validation logic. The issue was resolved in the 3.0.0 release, which is included in the 3.3.0 release set.

The CVSS score of 9.8 indicates critical severity, while the EPSS score of less than 1% suggests a low likelihood of widespread exploitation under current conditions. Nevertheless, the vulnerability can be exploited by any entity able to issue kernel launch requests with custom UID/GID parameters, making it highly relevant for environments that expose remote kernel creation APIs. Because the flaw can elevate privileges to the host level, repeated exploitation could compromise every worker node in the Kubernetes cluster, and the vulnerability is not yet listed in the CISA KEV catalog.