External risk intelligence

Jupyter Enterprise Gateway SSTI Allows Remote Code Execution and Cluster Compromise

CVE advisorySeverity: CRITICAL (CVSS 10.0)

CVE-2026-44181

Jupyter Enterprise Gateway is typically deployed as a centralized, network-accessible service to manage and coordinate distributed computing kernels across clusters, making it a common target for interaction within enterprise infrastructure and often positioned in network segments accessible to authorized users or integrated service endpoints.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

Jupyter Enterprise Gateway, which manages remote notebooks across clusters, has a critical vulnerability related to how it processes environment variables for Kubernetes manifests. This flaw allows attackers to potentially execute code on the gateway service, steal sensitive Kubernetes credentials, and gain full control over the cluster.

Code execution via template injection.
Threatens cluster control and data access.
Confirm relevance and exposure of your deployment.

Attack Path

How an attacker could exploit the issue

An attacker can exploit this by sending specially crafted environment variables to the Jupyter Enterprise Gateway. These variables, when processed by the gateway, contain template expressions that allow for the execution of arbitrary code on the service. This capability can be leveraged to steal sensitive Kubernetes credentials, ultimately leading to full compromise of the cluster.

Entry condition: Network access to the service.
Trigger point: Specially crafted environment variables.
Resulting risk: Kubernetes cluster compromise.

Live Threat

Current exploitation, exposure, and threat context

Jupyter Enterprise Gateway, when deployed to manage remote kernels on distributed systems, could allow an attacker to execute arbitrary Python code and operating system commands. This is possible by injecting malicious Jinja2 template expressions into environment variables used during the rendering of Kubernetes manifests. If successful, an attacker could gain access to the Kubernetes service account token, potentially leading to the theft of Kubernetes secrets and full cluster compromise.

Kubernetes secrets and cluster access.
Via malicious template injection.
Full Kubernetes cluster compromise.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts Jupyter Enterprise Gateway deployments, which are likely managed by platform or infrastructure teams responsible for distributed computing resources. The immediate priority is to identify all instances of the affected technology, ascertain their reachability and criticality to business operations, and confirm the accountable owner for each instance to begin risk-based remediation planning.

Platform/Infrastructure teams own the issue.
Verify affected instances and their exposure.
Plan remediation based on confirmed risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Jupyter Enterprise Gateway?

It is a server-side application designed to launch and manage Jupyter Notebook kernels across distributed computing environments. Organizations use it to coordinate workloads on platforms like Apache Spark, Kubernetes, and Docker Swarm, allowing data scientists to run notebook sessions on remote clusters rather than local machines.

What is the Server Side Template Injection vulnerability in CVE-2026-44181?

This is a weakness classified as CWE-1336, occurring when an application improperly handles user-supplied data within a template engine. In this case, the gateway processes environment variables as Jinja2 templates when building Kubernetes manifests. An attacker can input malicious template expressions that the engine interprets as executable code, rather than simple text, granting them unauthorized control over the gateway's underlying operating system.

How can an attacker trigger this vulnerability?

An attacker triggers this by providing specially crafted environment variables during the interaction with the gateway service. These inputs must contain specific Jinja2 template syntax that the service renders. Note that simply having the software installed is not enough; the attack requires sending these malicious inputs to the interface that processes Kubernetes configurations.

Is my deployment at risk according to Halo Surface Signal?

Halo Surface Signal identifies this as a likely target because Jupyter Enterprise Gateway is typically deployed as a centralized service. Because it is often configured to be network-accessible to coordinate distributed resources, it may be reachable by users or integrated services within your infrastructure, increasing the likelihood that it could be exposed to unauthorized interaction.

How do I fix CVE-2026-44181?

The primary resolution is to update your Jupyter Enterprise Gateway installation to version 3.3.0 or higher, where this processing flaw has been addressed. Before updating, identify all running instances of the gateway within your environment to ensure full coverage, confirm the owner of each deployment, and coordinate with your infrastructure or platform team to apply the update during your next maintenance cycle.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.