Summary
Jupyter Enterprise Gateway may embed attacker-controlled environment variables directly into Kubernetes YAML manifests without YAML-aware escaping. If an attacker can influence kernel environment variables, they may alter manifest structure, create additional resources, or override security-sensitive settings, including configurations that could enable privileged workloads.
Affected context
The vulnerability occurs in Enterprise Gateway deployments that launch kernels through Kubernetes and render manifests with untrusted environment variables. Template variables such as kernel_working_dir and other kernel_xxx values become risky when their contents are inserted into YAML without structural escaping or strict validation. The impact depends on the attacker's ability to influence kernel environment configuration and the permissions available to the resulting workloads.
Exploit preconditions
- Attack surface: Kubernetes manifest generation for remote Jupyter kernels
- Required access: Ability to control or influence kernel environment variables consumed by the manifest template
- Trigger point: Rendering and submission of the generated Kubernetes YAML
- Why exploitation is possible: Untrusted values are inserted as YAML syntax rather than being constrained to data-only values, allowing structure and resource boundaries to be changed
Why this happens
The underlying flaw is context-insensitive interpolation of untrusted values into a structured YAML document.
Values intended to represent ordinary configuration data are rendered into a Jinja2 Kubernetes manifest without YAML-aware escaping, schema enforcement, or sufficiently strict type validation. This permits injected YAML structure to be interpreted as additional or replacement configuration. The issue maps to CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component, because input is not neutralized for the syntax understood by the Kubernetes YAML parser.
Potential impact
- Additional Kubernetes resources could be created
- Security-sensitive manifest fields may be overwritten
- Workloads could run with excessive or privileged permissions
- Cluster resources or tenant workloads may be compromised
- Sensitive data could be exposed or altered
- Availability may be affected through unauthorized resource creation
General mitigation guidance
Mitigation generally focuses on preserving the boundary between configuration data and YAML structure.
Common defensive patterns include:
- Prefer Kubernetes client object models or structured serializers over string-based manifest interpolation
- Apply YAML-aware escaping and strict type and schema validation to every templated value
- Allowlist environment variables and permitted value formats, rejecting unexpected keys or structures
- Avoid accepting raw manifest fragments or document-boundary syntax from user-controlled input
- Run kernel workloads with least-privilege service accounts, restrictive security contexts, and narrowly scoped permissions
- Enforce admission policies that reject privileged or otherwise unsafe resource configurations
- Treat kernel environment configuration as untrusted unless its provenance and integrity are controlled
How teams detect issues like this
Detection can combine source review, runtime controls, and policy enforcement:
- Use static analysis to identify string interpolation of untrusted values into YAML or Kubernetes manifests
- Review Jinja2 templates for variables inserted without serialization filters or schema-backed rendering
- Flag code that constructs manifests through concatenation or unconstrained formatting rather than structured APIs
- Test rendered manifests with adversarial syntax, duplicate fields, unexpected types, and multiple-document input
- Enforce Kubernetes admission policies for privileged containers, host access, excessive capabilities, and unauthorized resource kinds
- Monitor generated manifests and API activity for unexpected resource types, duplicate security-related settings, or anomalous kernel workload creation
- Automated code review tools may help identify unsafe template-to-YAML data flows
