Jupyter Enterprise Gateway flaws expose Kubernetes clusters to RCE

At a glance

What this is: Orca Security says three critical Jupyter Enterprise Gateway flaws can let unauthenticated attackers reach remote code execution, privileged pod creation, and cluster compromise through YAML and template injection.

Why it matters: For IAM, Kubernetes, and platform teams, this is a reminder that workload identity, service account scope, and manifest rendering paths are part of the attack surface, not just application code.

By the numbers:

• CVE-2026-44182, CVE-2026-44181, and CVE-2026-44180 were rated CVSS 10.0, CVSS 10.0, and CVSS 9.8.

👉 Read Orca Security's analysis of Jupyter Enterprise Gateway RCE flaws in Kubernetes

Context

Jupyter Enterprise Gateway sits in the control path between notebook users and Kubernetes-backed kernel execution, which means flaws in its manifest rendering pipeline can become identity and privilege issues as quickly as they become application bugs. In practice, this is a workload identity problem as much as a code execution problem, because the service can create resources and act through Kubernetes permissions on behalf of users.

The article describes a dangerous pattern: user-supplied environment variables are interpolated into Jinja2 templates that generate Kubernetes manifests. When that rendering path fails to sanitize input, attackers can alter security-critical fields, inject extra resources, and move from a notebook-facing entry point to cluster-wide compromise.

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 notebook orchestration services create high-risk identity exposure?

A: Notebook orchestration services often sit close to cluster authority, so a flaw in the gateway can let attacker-controlled input influence workload identity, pod security, and service account reach. When those services can launch kernels or generate manifests, compromise can spread from a single user-facing component into Kubernetes permissions and shared infrastructure.

Q: How do security teams know whether Kubernetes launch controls are actually working?

A: They should test the final rendered workload, not just the upstream request or policy check. If an attacker can still alter securityContext, create additional documents, or bypass prohibited IDs after rendering, the control is not protecting the real execution path. Validation needs to cover the object that Kubernetes will actually admit.

Q: Who is accountable when a rendering flaw leads to cluster compromise?

A: Accountability spans application owners, platform teams, and identity governance functions because the failure crosses code, orchestration, and privileged access boundaries. Any framework that governs access control, workload identity, and configuration integrity applies here. The key question is whether the team owning the gateway also owns the authority it can emit.

Technical breakdown

YAML injection in manifest rendering

YAML injection occurs when attacker-controlled values are inserted into structured manifests without strict escaping or schema validation. In this case, environment variables can overwrite security-sensitive keys such as securityContext or expand into multi-document YAML that creates additional Kubernetes resources. Once the manifest is accepted, the cluster may treat the attacker’s injected content as legitimate orchestration input, not hostile payload. That makes the rendering layer a control boundary, not a convenience function.

Practical implication: treat manifest generation as a security boundary and validate every field before the manifest reaches Kubernetes.

Server-side template injection in Jupyter Enterprise Gateway

Server-side template injection, or SSTI, happens when untrusted values are evaluated by a template engine instead of being rendered as plain text. The article says KERNEL_XXX variables are interpolated without sanitization, which can let an attacker execute Python code and operating-system commands in the Enterprise Gateway service context. In a Kubernetes workflow, that means the compromise starts above the pod layer and can pivot into cluster-adjacent access, token theft, or workload manipulation depending on service permissions.

Practical implication: lock down template rendering paths and remove any trust in runtime variables that influence code or command execution.

Bypassing prohibited identity controls in Kubernetes kernels

One of the disclosed flaws bypasses the _enforce_prohibited_ids control intended to block kernel launches with UID or GID zero. If that guard can be bypassed, a user can shift from constrained execution into privileged containers and potentially escape into host filesystem access. This is a reminder that identity controls in Kubernetes are only as strong as the enforcement point. If the launch pipeline is compromised, policy exists on paper but not in practice.

Practical implication: verify that privileged identity restrictions are enforced after rendering, not only in pre-launch policy checks.

Threat narrative

Attacker objective: The attacker aims to turn a notebook orchestration service into a path for full Kubernetes cluster compromise.

1. Entry occurs through unauthenticated access to the Jupyter Enterprise Gateway rendering path, where attacker-controlled environment variables are accepted as kernel configuration input.
2. Escalation happens when YAML injection, SSTI, or prohibited-identity bypass lets the attacker execute code, create privileged pods, or steal Kubernetes service account tokens.
3. Impact follows as the attacker moves from the gateway into the cluster, enabling container escapes, host filesystem abuse, data exposure, and destructive actions against persistent volumes.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

This is not just an application RCE story. It is a workload identity failure in the manifest generation layer. Jupyter Enterprise Gateway sits close enough to Kubernetes authority that unsafe rendering turns user input into cluster action. The control failure is not only input validation, but the assumption that a manifest generator can safely mediate privileged orchestration without treating every rendered field as adversarial. Practitioners should read this as a governance problem for workload identity, not a single software defect.

Manifest rendering is an identity decision point, not a formatting step. Once template output can create pods, alter security context, or expose service account tokens, the renderer is effectively making access decisions on behalf of the platform. That means Kubernetes RBAC, pod security, and kernel launch policy all depend on the integrity of a path that is often designed as if it were low risk. The implication is that security teams must classify renderers by the privilege they can emit, not by the code they contain.

Over-trusting environment variables creates a privilege translation layer attackers can abuse. The article shows how a variable intended for kernel configuration can become a vehicle for code execution and resource creation. That pattern is especially dangerous in shared multi-tenant clusters, where one compromised rendering path can produce consequences that look like platform compromise rather than application abuse. Practitioners should treat configuration channels as identity-bearing inputs whenever they influence compute authority.

Privilege restrictions fail when they are checked before the attacker-controlled transformation, not after it. The bypass of prohibited IDs shows that a control can exist and still be functionally absent if the launch path lets malicious input alter the final workload shape. This is the same failure mode that appears whenever policy is enforced too early in a pipeline that later rewrites authority. The implication is to reassess where enforcement actually occurs in the orchestration chain.

Identity blast radius is the right concept for this class of vulnerability. A notebook-facing service with cluster permissions can convert a single unauthenticated flaw into a Kubernetes-wide event because the reachable authority is larger than the application surface suggests. That is exactly why NHI and workload identity governance need to be tied to runtime reachability, not just credential inventory. Teams should prioritize the maximum authority a service can emit under compromise.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%, according to The State of Non-Human Identity Security.
• For a broader control lens, read the 52 NHI Breaches Analysis for patterns that turn exposed access into repeatable compromise paths.

What this signals

Identity blast radius is the right way to think about orchestration services that can create resources on behalf of users. When a rendering path can emit privileged workloads, the security question is not whether the application is authenticated, but how far its authority extends if the path is manipulated. Teams should map that blast radius before they rely on the service in shared or internet-facing environments.

For platform and IAM teams, this is a reminder that workload identity governance and application security are converging. If manifest generation, service account scope, and pod security are managed separately, an attacker can exploit the seams rather than the controls. Aligning those functions under a single control view is now a practical necessity, not an architectural preference.

The governance signal is straightforward: if a service can create a pod, it can often create a problem larger than the code defect itself. Security programmes should track which components can translate user input into cluster authority and treat those components as high-value identity infrastructure. That is where the most consequential exposure tends to live.

For practitioners

• Patch Jupyter Enterprise Gateway immediately Upgrade affected deployments to version 3.3.0 and prioritize internet-facing instances and shared Kubernetes clusters first. Treat the upgrade as emergency remediation rather than normal maintenance because unauthenticated exploitation can convert a gateway bug into cluster compromise.
• Audit every kernel environment binding Review active environment variable bindings used for kernel configuration and remove any trust in values that can influence manifest generation, securityContext fields, or launch-time resource definitions.
• Constrain Kubernetes network and service account reach Apply restrictive Kubernetes network policies and reduce service account permissions for the Enterprise Gateway so a compromised renderer cannot move freely across namespaces or steal high-value tokens.
• Revalidate identity controls after rendering Check that controls such as prohibited UID or GID values are enforced on the final rendered workload, not only during initial request handling, and confirm that privileged pods cannot be created through template manipulation.

Key takeaways

• The disclosed flaws turn Jupyter Enterprise Gateway into a direct path from user input to Kubernetes authority, which is why the risk is broader than a normal application bug.
• The evidence points to unauthenticated YAML injection, SSTI, and control bypass as the mechanism for cluster compromise, privileged pod creation, and host-level impact.
• Immediate patching, manifest validation, and tighter workload identity boundaries are the controls most likely to prevent this class of failure from spreading across the cluster.

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.
• Workload Identity: Workload identity is the set of credentials, permissions, and trust relationships that allow a service or workload to act inside an environment. It matters because compromise of the workload often means compromise of the authority it can emit, including tokens, pods, APIs, and downstream resources.

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.

This post draws on content published by Orca Security: Jupyter Enterprise Gateway vulnerabilities that enable cluster compromise. Read the original.