TL;DR: Three critical Jupyter Enterprise Gateway vulnerabilities allow unauthenticated attackers to inject YAML and templates, execute arbitrary code, create privileged pods, and compromise Kubernetes clusters, according to Orca Security. The core issue is that manifest rendering trusted user-controlled inputs far too much for an environment that can directly shape cluster-level identity and privilege.
At a glance
What this is: Orca Security says three critical Jupyter Enterprise Gateway vulnerabilities allow unauthenticated RCE, privileged pod creation, and cluster compromise through manifest rendering flaws.
Why it matters: Kubernetes and IAM teams need to treat notebook orchestration services as privilege-bearing control points because unsafe manifest generation can expose service accounts, workloads, and cluster-wide access paths.
By the numbers:
- Three critical vulnerabilities affect Jupyter Enterprise Gateway and include CVE-2026-44182, CVE-2026-44181, and CVE-2026-44180.
- CVE-2026-44182 is rated CVSS 10.0.
- CVE-2026-44181 is rated CVSS 10.0.
- CVE-2026-44180 is rated CVSS 9.8.
Context
Jupyter Enterprise Gateway is a Kubernetes-based kernel orchestration component used to run remote notebook workloads. In this case, the security problem is not the notebook interface itself but the manifest rendering path that turns user-controlled variables into Kubernetes resources.
Orca Security says three flaws in that rendering path let unauthenticated attackers inject YAML, trigger server-side template injection, bypass UID and GID restrictions, and create privileged pods. For Kubernetes identity and access teams, this is a control-plane issue because rendered manifests can shape service account exposure, pod privilege, and cluster reachability.
The article's risk profile is strongest for internet-facing deployments and shared multi-tenant clusters, where a single gateway weakness can cross workload boundaries. That makes the issue relevant to workload identity, Kubernetes RBAC, and runtime isolation rather than just application patching.
Key questions
Q: What breaks when Kubernetes manifest rendering trusts user input?
A: When rendering trusts user input, attackers can inject YAML, alter security-critical fields, and create unintended Kubernetes resources. In a gateway that generates manifests for execution, that can turn a configuration bug into code execution, privileged pod creation, or service account token theft. The result is not just application compromise. It is a widened cluster-level attack path.
Q: Why do template injection flaws in orchestration services create cluster-wide risk?
A: Because the service that renders templates often sits close to workload creation and service account assignment. If an attacker can execute code or alter the manifest at that point, they can pivot from application compromise into pod privilege, token exposure, and cluster control. The risk scales with how much authority the renderer has over downstream resources.
Q: What signs show that a Kubernetes workload generator is too trusted?
A: Look for user-supplied values that can change securityContext, image, command, namespace, or resource creation, especially when the same path can emit multi-document YAML. Those are symptoms that the renderer is acting like an unreviewed policy engine. If a single input can change privilege shape, the trust boundary is already too wide.
Q: How should teams reduce the impact of a compromised notebook gateway?
A: Treat the gateway as a high-risk workload and constrain what its service account can create, reach, and read. Add namespace isolation, restrictive network policies, and admission checks that reject privileged pod specs even if a rendering bug is present. The goal is to keep a gateway compromise from becoming a cluster compromise.
Technical breakdown
How YAML injection turns manifest rendering into cluster control
Jinja2 template rendering becomes dangerous when untrusted variables are interpolated into Kubernetes manifests without strict sanitization. In this case, environment variables can overwrite security-sensitive fields such as securityContext and can inject multi-document YAML, which means the rendered output can create additional objects beyond the intended kernel resource. In a Kubernetes environment, that is enough to change scheduling, privilege, and resource shape before the API server ever evaluates the request. The risk is not abstract template abuse. It is a direct path from application input to cluster-level state change.
Practical implication: validate and constrain every manifest field that user input can influence before it reaches the Kubernetes API.
Why SSTI in Jupyter Enterprise Gateway becomes remote code execution
Server-side template injection occurs when attacker-controlled content is executed by the template engine rather than treated as data. Here, KERNEL_XXX variables are rendered without proper sanitization, allowing arbitrary Python code and operating system commands to run in the Enterprise Gateway service context. That matters because the gateway sits between users and Kubernetes kernels, so code execution there can become credential theft, pod manipulation, or a launch point for broader cluster abuse. Once the template engine is a code path, application-layer input validation stops being a cosmetic control and becomes a hard security boundary.
Practical implication: treat any render path that can execute template expressions as privileged code and remove user influence from it.
How UID and GID bypasses undermine pod and host isolation
The _enforce_prohibited_ids control was intended to stop kernel launches running as UID 0 or GID 0, but the flaw lets attackers bypass that safeguard. When those restrictions fail, a workload can gain elevated container privileges, and in Kubernetes that often becomes a stepping stone to container escape attempts or host filesystem abuse. The issue shows why identity controls inside workload orchestration cannot rely on a single application-side check. If the control can be bypassed during resource generation, the resulting pod spec can inherit privilege that the operator never intended to grant.
Practical implication: enforce privileged workload restrictions at multiple layers, not only inside the application that generates the pod spec.
Threat narrative
Attacker objective: The attacker wants cluster-level execution and privilege that can be used to control workloads, steal service account tokens, and disrupt or exfiltrate data from the Kubernetes environment.
- Entry occurs through unauthenticated access to the Jupyter Enterprise Gateway rendering path, where attacker-controlled environment variables are accepted as input.
- Credential or privilege abuse follows when YAML and template injection let the attacker shape Kubernetes manifests, including securityContext overrides and privileged pod creation.
- Escalation continues as arbitrary Python code or OS commands run inside the Enterprise Gateway service, enabling token theft and further access to cluster resources.
- Impact is full Kubernetes cluster compromise, including container escapes, host filesystem abuse, data exposure, and destructive actions against persistent volumes.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Manifest rendering is part of the trust boundary, not a convenience layer: Orca Security's findings show that user-controlled environment variables in Kubernetes manifest generation can directly manufacture privilege. Once security-critical fields such as securityContext are writable through templates, the application is no longer assembling configuration, it is authorising cluster state. Practitioners should treat manifest rendering as a governed control point, not a string-processing task.
YAML injection in a Kubernetes orchestration service is an identity event: The problem is not just malformed output, but the ability to create privileged workload identities and resource objects from untrusted input. That changes the governance question from
to who or what is allowed to shape workload privilege at generation time. The practical implication is that Kubernetes RBAC and workload policy must assume the renderer itself is a high-risk identity producer.
Template execution collapses the separation between data and command: When Jinja2 expressions can execute Python and OS commands, the gateway becomes an execution broker rather than an orchestration helper. That means the surrounding security model must account for code execution inside the service before any Kubernetes control is involved. Practitioners should reclassify template paths that accept user input as high-risk execution surfaces.
Standing assumptions about pod restrictions do not survive render-time manipulation: The control idea that a gateway can reliably block UID 0 and GID 0 was designed for a pipeline where the final spec remains faithful to policy. That assumption fails when the actor can alter the generated manifest before launch because the resulting pod may already contain the privilege it was meant to prevent. The implication is that workload identity and pod privilege governance must be enforced after generation as well as before it.
From our research library:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
What this signals
Manifest generation should be governed like privilege assignment: The security issue here is not simply RCE, but the ability of an application to write privilege-bearing Kubernetes resources from untrusted input. That means Kubernetes teams should move review effort upstream, focusing on who can influence rendered manifests and what downstream authority those manifests can express.
Render-to-run control is the real boundary: If a gateway can alter pod security settings, create additional resources, or bypass UID and GID restrictions, then patching the application alone is not a complete governance answer. Practitioners need to watch the entire path from template input to admitted workload, because that is where privilege is actually introduced and enforced.
Workload identity controls fail when the manifest itself is compromised: Service account scope, namespace boundaries, and network policy still matter, but they only help if the generated workload spec is trustworthy. In environments where notebook orchestration can shape cluster objects, identity governance has to cover both creation-time policy and runtime containment.
For practitioners
- Upgrade affected Enterprise Gateway deployments Move all affected instances to Jupyter Enterprise Gateway 3.3.0 immediately, starting with internet-facing and shared multi-tenant clusters.
- Audit environment variable bindings for kernel launches Review every KERNEL_XXX binding and other user-influenced values that feed manifest rendering, then remove or hard-limit any path that can alter security-critical fields.
- Constrain Kubernetes RBAC for the gateway service account Reduce service account permissions so the gateway can create only the kernel resources it truly needs, with no ability to write privileged pods or secrets.
- Apply restrictive network policies around notebook workloads Use Kubernetes network policies to limit lateral movement from gateway-managed pods to other namespaces, control-plane endpoints, and sensitive services.
- Re-check pod security and admission controls Enforce guardrails that block privileged pod specs, UID 0 and GID 0 launches, and unexpected resource creation even if the rendered manifest is tampered with.
Key takeaways
- The core problem is not just a vulnerability in Jupyter Enterprise Gateway, but a manifest rendering path that lets untrusted input create privileged Kubernetes resources.
- Orca Security reports three critical issues, including two CVSS 10.0 flaws and one CVSS 9.8 flaw, with no authentication required.
- Immediate patching, tighter RBAC, and stronger pod and network controls are necessary to stop a gateway compromise from becoming a cluster compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Manifests generated from untrusted input can create insecure Kubernetes deployments. |
| NHI-05 — Overprivileged NHI | Privileged pods and excessive service account scope are central to the compromise path. | |
| Recommendation — Harden manifest generation paths so untrusted input cannot create insecure Kubernetes resources. Reduce service account and pod privilege so a renderer compromise cannot inherit broad access. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The vulnerable service misconfigures template handling and output validation at the API boundary. |
| Recommendation — Validate rendered output before it reaches cluster APIs and reject unexpected privilege-bearing fields. | ||
| MITRE ATT&CK | TA0006;TA0008;TA0004 — Credential Access; Lateral Movement; Privilege Escalation | The exploit chain reaches token theft, cluster spread, and privilege gain. |
| Recommendation — Map the exploit path to credential access, lateral movement, and privilege escalation detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Gateway-generated workloads need tightly bounded entitlements and authorization scope. |
| PR.DS-01 — Data-at-rest is protected | Cluster compromise can expose sensitive configurations and secrets stored in workloads. | |
| Recommendation — Apply PR.AA-05 to limit what the gateway service account and generated pods can access. Protect sensitive Kubernetes data so a compromised gateway cannot trivially read secrets. | ||
Key terms
- Manifest Rendering: Manifest rendering is the process of turning configuration values into Kubernetes objects that the cluster can accept and run. In secure systems, the renderer must preserve structure, enforce schema, and reject hostile input, because it is effectively translating trust from a user-facing request into deployment authority.
- Server-Side Template Injection: Server-side template injection occurs when untrusted data is interpreted by a template engine as executable template syntax. In identity and platform systems, it can become a privilege problem because the attack executes inside a service that may already hold access to cluster resources, tokens, or other sensitive controls.
- Privileged Pod: A privileged pod is a Kubernetes workload granted elevated container permissions that can expand its access to host resources and system functions. These pods increase the impact of compromise and configuration error. Security teams usually restrict them because they weaken isolation and create a larger attack surface.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org