CVE-2026-44181 is a critical server side template injection (CVSS 10.0) in Jupyter Enterprise Gateway versions from 2.0.0rc2 up to 3.2.3. Kernel environment variables are rendered through Jinja2 when building Kubernetes manifests, which can run code in the gateway. Upgrade to 3.3.0 or later.
What's affected
The record and the project advisory give these ranges for the jupyter_enterprise_gateway package on PyPI:
- Affected: 2.0.0rc2 and above, before 3.3.0 (the advisory lists the affected range as 2.0.0rc2 and later, with 3.3.0 as the patched version).
- Fixed: 3.3.0.
The weakness sits in the Kubernetes process proxy, so the exposure applies to deployments that launch kernels as Kubernetes pods. The advisory describes the Enterprise Gateway service account as holding read and write access to pods, secrets, namespaces, role bindings and other resource kinds, which is why the impact is rated so high.
A companion issue in the same release, CVE-2026-44182, covers YAML injection in the same manifest rendering path. Both are fixed in 3.3.0.
How to check if you're exposed
Find the installed version in the environment or image that runs the gateway:
pip show jupyter_enterprise_gateway
If you deploy from a container image, check the image tag in your Deployment:
kubectl get deploy -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i enterprise
Any version below 3.3.0 is in range. Also confirm which clients can reach the gateway API, since the attack input arrives through the kernel start request.
What to do now
- Upgrade Jupyter Enterprise Gateway to 3.3.0 or later and redeploy the Kubernetes workloads that run it.
- Limit network access to the gateway API to trusted notebook clients and gateways. Do not expose it to the internet.
- Review the gateway service account permissions and cut them to what kernel launching needs.
- Look at recent kernel start requests and the pods they created for unusual names, namespaces or privileged settings.
- If you suspect misuse, rotate the secrets the service account could read and check the cluster for unexpected pods and role bindings.
Why it matters
The weakness class is CWE-1336 (improper neutralization of special elements used in a template engine). The gateway took values from KERNEL_ environment variables, such as the pod name, and handed them to Jinja2 as template source. A template engine treats its input as instructions, so a value that contains template syntax can run Python code instead of being stored as plain text.
What turns this from a bug into a cluster problem is where the code runs. It runs inside the gateway, which holds a Kubernetes service account token. The advisory says that token can be used to read secrets and to schedule a privileged pod or one with a host path mount. The record does not mark this CVE as KEV, and the advisory does not report exploitation.
The safe pattern is to pass user supplied values into a template as data, never to render them as the template itself, and to escape for the output format (here YAML).
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect non-Kubernetes deployments?
The advisory describes the flaw in the Kubernetes kernel launcher and manifest template. If you do not use the Kubernetes process proxy, confirm that with the project advisory, and upgrade anyway.
Is 3.3.0 enough for both related CVEs?
Yes for the two gateway CVEs named here. The release notes for 3.3.0 are linked in the sources.
Sources
Last reviewed: 19 October 2026.
