CVE-2026-44182: Jupyter YAML injection → K8s

CISO Take

Jupyter Enterprise Gateway contains a critical YAML injection flaw in its Kubernetes manifest renderer: untrusted KERNEL_XXX environment variables supplied by API callers are interpolated into Jinja2 pod templates without escaping, allowing attackers to overwrite pod security contexts — elevating containers to root — or inject multi-document YAML separators to create fully independent privileged Kubernetes resources. With 1,872 downstream dependents, a working proof-of-concept published in the GitHub security advisory, and an OpenSSF Scorecard of only 5.2/10 signaling persistent security hygiene issues, any organization running Jupyter on Kubernetes for AI/ML workloads faces realistic risk of full cluster compromise: repeated exploitation can pivot from a single injected privileged pod to all worker nodes via hostPath mounts and kernel module loading. Upgrade to jupyter_enterprise_gateway 3.3.0 immediately; if patching is delayed, firewall the Gateway API port from untrusted networks and monitor kernel namespaces for unexpected pods with privileged securityContexts.

Sources: GitHub Advisory NVD OpenSSF ATLAS

What is the risk?

Critical. The attack requires only HTTP access to the Enterprise Gateway API endpoint and no AI/ML knowledge whatsoever, placing it firmly in the trivially exploitable category for any attacker with network reach. The blast radius is severe: successful exploitation grants root-level container execution, Kubernetes resource creation across six privileged resource types (Pod, Secret, PersistentVolumeClaim, PersistentVolume, Service, ConfigMap), and multiple container escape vectors — hostPath R/W mounts combined with root access enable crontab injection on the host, and privileged pod mode enables kernel module loading. Multi-tenant AI/ML platforms (JupyterHub enterprise deployments, cloud-native data science workbenches) running on shared Kubernetes clusters face the highest exposure, as a single malicious API call can compromise the entire cluster and all ML workloads running on it.

How does the attack unfold?

API Access

Attacker sends a crafted POST to /api/kernels with KERNEL_XXX environment variables containing embedded YAML line breaks and injected field content.

AML.T0049

YAML Injection

Enterprise Gateway's Jinja2 template interpolates the unsanitized KERNEL_WORKING_DIR value into the Kubernetes pod manifest, injecting malicious securityContext fields and document boundary separators.

AML.T0050

Privilege Escalation

Kubernetes parses the poisoned multi-document manifest and creates a privileged pod with runAsUser: 0 and a hostPath volume mount granting read-write access to the worker node's root filesystem.

Cluster Compromise

Attacker leverages root host filesystem access to establish persistent execution on the node (via crontab injection or kernel module loading), then pivots laterally to compromise additional nodes and the full cluster.

AML.T0105

API Access

Attacker sends a crafted POST to /api/kernels with KERNEL_XXX environment variables containing embedded YAML line breaks and injected field content.

AML.T0049

YAML Injection

Enterprise Gateway's Jinja2 template interpolates the unsanitized KERNEL_WORKING_DIR value into the Kubernetes pod manifest, injecting malicious securityContext fields and document boundary separators.

AML.T0050

Privilege Escalation

Kubernetes parses the poisoned multi-document manifest and creates a privileged pod with runAsUser: 0 and a hostPath volume mount granting read-write access to the worker node's root filesystem.

Cluster Compromise

Attacker leverages root host filesystem access to establish persistent execution on the node (via crontab injection or kernel module loading), then pivots laterally to compromise additional nodes and the full cluster.

AML.T0105

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	< 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.5%

chance of exploitation in 30 days

Higher than 40% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

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 immediately: upgrade to jupyter_enterprise_gateway>=3.3.0, which introduces YAML-aware escaping for kernel environment variables.
Restrict API access: firewall the Enterprise Gateway port and require authenticated access — never expose the API to untrusted networks or the public internet.
Reduce attack surface: disable EG_MIRROR_WORKING_DIRS (set mirrorWorkingDirs: false in the Helm chart) if working directory mirroring is not required — this eliminates the KERNEL_WORKING_DIR injection vector specifically.
Detect exploitation: monitor Kubernetes audit logs for unexpected pod creation in kernel namespaces; alert on any pod spec containing privileged: true, runAsUser: 0, or unexpected hostPath volume mounts created by the Enterprise Gateway service account.
Audit existing workloads: inspect all running pods in kernel namespaces for anomalous specs that may indicate prior exploitation before patching.

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 Auth Bypass Framework Inference AML.T0010.001 - AI Software AML.T0049 - Exploit Public-Facing Application AML.T0050 - Command and Scripting Interpreter AML.T0105 - Escape to Host

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2 - AI risk management A.8.2 - AI system security

NIST AI RMF

MS-2.5 - Practices and procedures to address AI risks

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-44182?

Jupyter Enterprise Gateway contains a critical YAML injection flaw in its Kubernetes manifest renderer: untrusted KERNEL_XXX environment variables supplied by API callers are interpolated into Jinja2 pod templates without escaping, allowing attackers to overwrite pod security contexts — elevating containers to root — or inject multi-document YAML separators to create fully independent privileged Kubernetes resources. With 1,872 downstream dependents, a working proof-of-concept published in the GitHub security advisory, and an OpenSSF Scorecard of only 5.2/10 signaling persistent security hygiene issues, any organization running Jupyter on Kubernetes for AI/ML workloads faces realistic risk of full cluster compromise: repeated exploitation can pivot from a single injected privileged pod to all worker nodes via hostPath mounts and kernel module loading. Upgrade to jupyter_enterprise_gateway 3.3.0 immediately; if patching is delayed, firewall the Gateway API port from untrusted networks and monitor kernel namespaces for unexpected pods with privileged securityContexts.

Is CVE-2026-44182 actively exploited?

No confirmed active exploitation of CVE-2026-44182 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-44182?

1. Patch immediately: upgrade to jupyter_enterprise_gateway>=3.3.0, which introduces YAML-aware escaping for kernel environment variables. 2. Restrict API access: firewall the Enterprise Gateway port and require authenticated access — never expose the API to untrusted networks or the public internet. 3. Reduce attack surface: disable EG_MIRROR_WORKING_DIRS (set mirrorWorkingDirs: false in the Helm chart) if working directory mirroring is not required — this eliminates the KERNEL_WORKING_DIR injection vector specifically. 4. Detect exploitation: monitor Kubernetes audit logs for unexpected pod creation in kernel namespaces; alert on any pod spec containing privileged: true, runAsUser: 0, or unexpected hostPath volume mounts created by the Enterprise Gateway service account. 5. Audit existing workloads: inspect all running pods in kernel namespaces for anomalous specs that may indicate prior exploitation before patching.

What systems are affected by CVE-2026-44182?

This vulnerability affects the following AI/ML architecture patterns: Jupyter/JupyterHub on Kubernetes, ML training pipelines, Multi-tenant notebook environments, AI/ML development infrastructure, Kubernetes-based model serving.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Jupyter/JupyterHub on KubernetesML training pipelinesMulti-tenant notebook environmentsAI/ML development infrastructureKubernetes-based model serving

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0049 Exploit Public-Facing Application

AML.T0050 Command and Scripting Interpreter

AML.T0105 Escape to Host

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2, A.8.2

NIST AI RMF: MS-2.5

OWASP LLM Top 10: 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 prior to 3.3.0, the server interpolates untrusted environment variables (e.g., KERNEL_XXX) into Kubernetes manifests without YAML-aware escaping, enabling YAML injection attacks. Attackers can inject new fields, overwrite critical fields (e.g., duplicate securityContext keys, where the last one prevails), and inject document boundaries (--- for new documents, ... for end-of-document) to generate multiple resources, potentially creating arbitrary types, such as privileged pods. The Jinja2 template for the Kubernetes manifest contains several kernel_xxx variables, such as kernel_working_dir that are used when rendering the manifest and are all vectors for YAML injection. This issue has been fixed in version 3.3.0.

Exploitation Scenario

An attacker with access to the Enterprise Gateway API — a malicious platform user, a compromised Jupyter session, or an external attacker if the API is network-exposed — crafts a POST to /api/kernels with a KERNEL_WORKING_DIR value embedding YAML line breaks and injected securityContext fields. The Gateway's Jinja2 template interpolates this value unescaped into the Kubernetes pod manifest, producing valid multi-document YAML: the first document overwrites the legitimate pod's securityContext with runAsUser: 0, and injected document separators (--- and ...) cause Kubernetes to parse and apply a second fully independent pod spec with privileged: true and a hostPath volume mounting the worker node's root filesystem at /host. The injected pod starts within seconds; the attacker mounts the host filesystem read-write, writes a crontab entry to the host's /etc/cron.d directory, and achieves persistent root-level code execution on the underlying worker node — enabling lateral movement to additional nodes and full cluster compromise including theft of all secrets, model artifacts, and training data.

Weaknesses (CWE)

CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') Primary CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') Primary CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

CWE-74 — Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'): The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.

[Requirements] Programming languages and supporting technologies might be chosen which are not subject to these issues.
[Implementation] Utilize an appropriate mix of allowlist and denylist parsing to filter control-plane syntax from all input.

Source: MITRE CWE corpus.