By While assessing an AI platform, we identified three vulnerabilities inJupyter Enterprise Gatewaythat allow a notebook user with no Kubernetes privileges to compromise the underlying cluster. In this post we walk through how a notebook user can escalate from running data science workloads to reading cluster secrets, mounting host filesystems, and creating arbitrary privileged pods. We responsibly disclosed these issues to the Jupyter security team, who have since published a patched release in v3.3.0. Each issue has been assigned a CVE: Our full advisories including proof-of-concept exploits and Nuclei templates for each issue are published in ourGitHub repository. The rest of this post walks through each vulnerability and covers hardening recommendations. Jupyter Enterprise Gateway is a top-level Jupyter project that extends Jupyter Notebook and JupyterHub to launch kernels remotely on distributed compute infrastructure - including Kubernetes, Apache Spark, and others. In a standard local Jupyter setup, the kernel (the Python process that actually executes your code) runs on the same machine as the notebook server. Enterprise Gateway decouples these: the notebook server stays where it is, but kernel execution is delegated to a remote cluster. This is a common pattern for sharing GPU and CPU compute across users and workloads on AI platforms. In a Kubernetes deployment, when a user opens a notebook and runs a cell, the notebook server calls Enterprise Gateway's REST API to request a kernel. Enterprise Gateway then creates a Kubernetes pod - the kernel pod - in which the user's code actually runs. Enterprise Gateway acts as a privileged intermediary: it holds a Kubernetes service account with broad permissions to create, list, and delete pods, secrets, namespaces, persistent volumes, and more. Consider a corporate data science platform where dozens of analysts and data scientists share a Jupyter environment backed by Enterprise Gateway. These users - call one Mallory - have legitimate notebook access, but they are not Kubernetes cluster administrators. The cluster likely hosts other sensitive workloads: production services, databases, internal tooling. Mallory is not supposed to be able to touch any of that. But Enterprise Gateway's API accepts user-controlled values that influence how kernels are launched. These values can be weaponised in two ways: through the notebook server, which may forward user-controlled environment variables to Enterprise Gateway; or directly against the Enterprise Gateway API - including by hairpinning from within a kernel pod if the cluster's network policy allows more than the ZMQ backchannel to Enterprise Gateway. Either path lets a notebook user leverage Enterprise Gateway's elevated Kubernetes service account privileges to compromise the entire cluster and every workload running on it. To illustrate the vulnerabilities, we created a Kubernetes cluster and deployed a vulnerable version (v3.2.3) of Jupyter Enterprise Gateway using Helm.