Critical Jinja2 SSTI Flaw in Jupyter Enterprise Gateway Enables Kubernetes RCE (CVE-2026-44181)

A critical vulnerability in Jupyter Enterprise Gateway allows unauthenticated attackers to execute remote code and potentially seize control of entire Kubernetes clusters, according to a security advisory published by the maintainer, lresende.

Tracked as CVE-2026-44181 and carrying a maximum CVSS v4 base score reflecting Critical severity, the flaw stems from unsafe Jinja2 template rendering and impacts organizations running Jupyter-based data science and machine learning workloads on Kubernetes.

The vulnerability, cataloged as GHSA-f49j-v924-fx9w, was discovered by security researcher ben-elttam and affects all versions of jupyter_enterprise_gateway from v2.0.0rc2 onward. A patch is available in version 3.3.0.

Critical Jinja2 SSTI Flaw

Jupyter Enterprise Gateway acts as a web-based gateway that provisions Jupyter kernels as pods inside Kubernetes clusters. When a client requests a new kernel, the service accepts environment variables prefixed with KERNEL_ and uses them to render a Kubernetes pod manifest via a Jinja2 template.

The problem lies in how the KERNEL_POD_NAME variable—and other KERNEL_XXX fields like kernel_working_dir, are handled. Rather than treating these values as plain strings, the code in k8s.py checks for the presence of {{ and }}, then explicitly renders the input as a Jinja2 template using env.from_string(pod_name).render(**keywords).

This is a textbook Server-Side Template Injection (SSTI) flaw, classified under CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine).

Because Jinja2 templates can access Python’s object hierarchy, attackers can escape the sandbox entirely. A trivial proof-of-concept using {{7 * 7}} in the KERNEL_POD_NAME field confirms code evaluation, resulting in a pod literally named bdawg-49.

Weaponizing this further, researchers demonstrated full OS command execution by chaining through cycler.__init__.__globals__.os.popen() a well-known Jinja2 sandbox escape technique to run arbitrary shell commands like hostname on the Enterprise Gateway pod itself.

What elevates this bug from “critical” to genuinely nightmarish is the Enterprise Gateway service account’s Kubernetes RBAC permissions.

Once an attacker achieves code execution inside the pod, they can steal the mounted service account token and inherit its privileges, which include full get/watch/list/create/delete access to pods, secrets, configmaps, persistent volumes, namespaces, and services.

With that access, an attacker can read Kubernetes secrets across namespaces, tamper with other running Jupyter kernels, or most dangerously, schedule a new pod with a hostPath volume mount or run it in privileged mode.

Either technique is a well-documented path to breaking out of container isolation and achieving root access on the underlying node, effectively compromising the entire cluster.

The CVSS v4 vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H confirms this is remotely exploitable over the network with no authentication, no user interaction, and low complexity, while causing high impact to confidentiality, integrity, and availability on both the vulnerable system and connected systems.

“SSTI vulnerabilities in infrastructure-provisioning code are especially dangerous because the blast radius isn’t just the application it’s every workload the service account can touch. When your template engine has a direct line to os.popen(), you’re not patching a bug, you’re patching a backdoor,” says [INSERT ORIGINAL QUOTE/OPINION].

Remediation

Organizations running self-managed Jupyter Enterprise Gateway on Kubernetes should upgrade to version 3.3.0 immediately.

As a compensating control, teams unable to patch immediately should audit and restrict the Enterprise Gateway service account’s RBAC bindings, following least-privilege principles, and monitor for anomalous pod creation events tied to kernel provisioning requests.