CVE-2026-44182 - Jupyter Enterprise Gateway YAML manifest injection

Jupyter Enterprise Gateway versions before 3.3.0 can render user-controlled KERNEL_* environment values into Kubernetes YAML manifests without YAML-aware escaping. A malicious value can change the structure of the kernel pod manifest, override security fields, or inject additional Kubernetes documents and resource kinds.

This is not just a malformed manifest issue. Enterprise Gateway kernel launch often has permission to create pods and related resources in notebook namespaces. YAML injection can turn a normal kernel request into privileged pod creation, unexpected services, config maps, secrets, persistent volumes, claims, or hostPath-mounted workloads. A reviewable fix must prove that user-influenced values are serialized as data and that the rendered output contains only the intended resource shape.

When to use it

Use this recipe when a repository, notebook platform, or Kubernetes-backed Jupyter Enterprise Gateway deployment renders kernel manifests from user controlled KERNEL_* values. It supports source-code remediation, YAML-safe manifest rendering, Kubernetes privilege review, and audit evidence that kernel launch inputs cannot inject privileged resources.

Inputs

  • jupyter_enterprise_gateway version, kernel spec templates, Kubernetes manifest renderer, service account policy, namespace policy, and deployment config.
  • Source paths that copy KERNEL_* values into YAML, render pod manifests, create Kubernetes resources, or validate kernel launch requests.
  • Regression fixtures for YAML structure breaks, document separators, privileged pod fields, benign env values, and expected reject/escape behavior.
  • Boundary evidence: service-account permissions, namespace scope, admission controls, generated manifests, audit logs, and impacted kernels.

Affected versions

  • Vulnerable package: jupyter_enterprise_gateway <3.3.0
  • Fixed package: jupyter_enterprise_gateway 3.3.0+
  • Affected surface: Enterprise Gateway Kubernetes kernel manifest rendering
  • Affected input shape: user-influenced KERNEL_* values rendered into YAML scalar positions without YAML-aware serialization
  • Related recipes: CVE-2026-44181 covers Jinja2 SSTI in the same rendering boundary; CVE-2026-44180 covers UID/GID prohibited-ID bypass

Indicator-of-exposure

  • The repository depends on, vendors, builds, or deploys jupyter_enterprise_gateway <3.3.0.
  • Enterprise Gateway uses Kubernetes process proxies, kernel pod templates, JupyterHub notebook platforms, ML workbenches, agent notebook workspaces, or remote kernel services.
  • Kernel launch requests can pass env values from notebook users, tenants, uploaded notebooks, model output, CI jobs, support tools, or automation.
  • KERNEL_WORKING_DIR, KERNEL_POD_NAME, KERNEL_NAMESPACE, KERNEL_UID, KERNEL_GID, image, volume, annotation, label, or custom kernel variables are inserted into YAML text.
  • EG_MIRROR_WORKING_DIRS, Helm mirrorWorkingDirs, custom kernelspec env passthrough, or user-controlled working-directory mirroring is enabled.

Quick checks:

rg -n "jupyter_enterprise_gateway|enterprise-gateway|enterprisegateway|kernel-pod.yaml.j2|KERNEL_WORKING_DIR|EG_MIRROR_WORKING_DIRS|mirrorWorkingDirs|KERNEL_POD_NAME|KERNEL_NAMESPACE|KERNEL_UID|KERNEL_GID|yaml.safe_load|safe_load_all|yaml.dump|safe_dump|render" .
python -m pip show jupyter_enterprise_gateway
pip freeze | rg "^jupyter-enterprise-gateway==|^jupyter_enterprise_gateway=="
rg -n "jupyter[_-]enterprise[_-]gateway|EnterpriseGateway|kernel-pod.yaml.j2|KERNEL_|mirrorWorkingDirs|hostPath|privileged|ClusterRole|RoleBinding|PersistentVolume|securityContext" Dockerfile* docker-compose*.yml pyproject.toml requirements*.txt environment*.yml charts k8s deploy .devcontainer .github .

Windows:

rg -n "jupyter_enterprise_gateway|enterprise-gateway|enterprisegateway|kernel-pod.yaml.j2|KERNEL_WORKING_DIR|EG_MIRROR_WORKING_DIRS|mirrorWorkingDirs|KERNEL_POD_NAME|KERNEL_NAMESPACE|KERNEL_UID|KERNEL_GID|yaml.safe_load|safe_load_all|yaml.dump|safe_dump|render" .
python -m pip show jupyter_enterprise_gateway
pip freeze | rg "^jupyter-enterprise-gateway==|^jupyter_enterprise_gateway=="
rg -n "jupyter[_-]enterprise[_-]gateway|EnterpriseGateway|kernel-pod.yaml.j2|KERNEL_|mirrorWorkingDirs|hostPath|privileged|ClusterRole|RoleBinding|PersistentVolume|securityContext" Dockerfile* docker-compose*.yml pyproject.toml requirements*.txt environment*.yml charts k8s deploy .devcontainer .github .

Do not submit multi-document YAML probes to live Enterprise Gateway services, schedule unexpected resources, mount host paths, or inspect cluster secrets during triage.

Remediation strategy

  • Upgrade every controlled Enterprise Gateway runtime, Python lock, image, Helm chart, deployment manifest, SBOM, and runbook to jupyter_enterprise_gateway 3.3.0+.
  • If this repository owns Enterprise Gateway forks, wrappers, custom process proxies, or manifest rendering, construct Kubernetes manifests as structured data and serialize with a YAML-safe emitter instead of concatenating YAML.
  • Enforce expected field types before rendering. Scalar-only fields should not accept newlines, document separators, block scalars, anchors, aliases, duplicate keys, mapping fragments, list fragments, or type-changing values.
  • After rendering test manifests, parse with a duplicate-key-aware loader and assert there is exactly the intended object set and security context.
  • Disable or constrain user-controlled working-directory mirroring until the fixed version and YAML-safe rendering path are deployed.
  • Keep Kubernetes admission controls as a backstop: restricted Pod Security, no privileged pods, no hostPath mounts for untrusted kernels, and least-privilege Enterprise Gateway RBAC.

The prompt

You are remediating CVE-2026-44182 / GHSA-cfw7-6c5v-2wjq, a critical Jupyter
Enterprise Gateway Kubernetes YAML injection where user-controlled `KERNEL_*`
values can alter rendered kernel manifests or inject additional Kubernetes
resources. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Enterprise Gateway, renders
  Kubernetes manifests with YAML-safe data handling, prevents unexpected
  resource injection, refreshes generated artifacts, and documents operator
  cleanup, or
- TRIAGE.md if this repository does not control an affected Enterprise Gateway
  runtime, fork, wrapper, kernel template, image, or deployment.

## Rules

- Scope only CVE-2026-44182 / GHSA-cfw7-6c5v-2wjq and directly related
  Enterprise Gateway Kubernetes manifest serialization, working-directory
  mirroring, and cluster policy hardening.
- Also check whether the same Enterprise Gateway deployment is affected by
  CVE-2026-44180 and CVE-2026-44181, but do not broaden into unrelated Jupyter
  issues unless they share the same manifest-rendering boundary.
- Treat service-account tokens, Kubernetes secrets, notebook files, PVC
  contents, dataset mounts, cloud credentials, Git credentials, SSH keys,
  cluster inventory, pod logs, and user environment variables as sensitive.
- Do not submit multi-document YAML probes, schedule privileged pods, create
  unexpected cluster resources, mount host paths, inspect live secrets, or run
  container-escape checks.
- Do not print or commit rendered manifests that include secrets, real
  environment variables, service-account token paths, notebook output, pod
  logs, or cluster credentials.
- Do not rely on line-oriented escaping, deny-lists, UI-only validation, or
  admission controls as the only fix.
- Do not auto-merge.

## Steps

1. Inventory every repository-controlled Enterprise Gateway reference:
   Python manifests, lockfiles, Conda files, Dockerfiles, JupyterHub images,
   Helm charts, Kubernetes manifests, Terraform, Ansible, CI images,
   kernelspecs, kernel pod templates, SBOMs, generated dependency reports,
   platform runbooks, forks, launch wrappers, and custom process proxies.
2. Determine every resolved `jupyter_enterprise_gateway` version. A target is
   vulnerable if it resolves to `<3.3.0`.
3. Search for YAML-rendering and working-directory paths:
   `kernel-pod.yaml.j2`, `KERNEL_WORKING_DIR`, `EG_MIRROR_WORKING_DIRS`,
   `mirrorWorkingDirs`, `safe_load`, `safe_load_all`, `safe_dump`, `render`,
   `KERNEL_POD_NAME`, `KERNEL_NAMESPACE`, labels, annotations, volumes,
   mounts, and custom `KERNEL_*` substitutions.
4. Determine who can influence kernel launch environment: notebook users,
   tenants, agents, uploaded notebooks, model output, CI jobs, support users,
   API clients, or administrators only.
5. Inventory Enterprise Gateway RBAC and namespace policy: service accounts,
   roles, rolebindings, cluster roles, secret permissions, pod creation,
   service creation, config-map creation, PVC/PV access, hostPath allowance,
   privileged workloads, and namespace admission controls.
6. If this repository does not control an affected Enterprise Gateway runtime,
   stop with `TRIAGE.md` listing checked files, runtime owner if known, and
   required fixed version `jupyter_enterprise_gateway 3.3.0+`.
7. Upgrade all controlled Enterprise Gateway packages and images to `3.3.0+`.
   Regenerate Python locks, Conda files, image digests, Helm render output,
   SBOMs, dependency reports, and docs that pin vulnerable versions.
8. Where this repository owns manifest rendering, make YAML generation fail
   closed:
   - build Kubernetes resources as typed objects or dictionaries before
     serialization;
   - serialize with a YAML-safe emitter instead of concatenating YAML strings;
   - validate user-influenced values against expected field types;
   - reject document separators, block scalars, anchors, aliases, duplicate
     keys, mapping fragments, list fragments, control characters, and newlines
     in scalar-only fields;
   - parse rendered test manifests with a duplicate-key-aware loader and assert
     the expected object count, kinds, names, namespaces, and security context.
9. Add containment when an upgrade cannot deploy atomically:
   - disable user-controlled working-directory mirroring;
   - block untrusted kernel env passthrough;
   - route untrusted notebooks to reduced-trust namespaces;
   - deny privileged pods, hostPath mounts, host networking, and privilege
     escalation at admission.
10. Add reviewer-safe tests:
    - vulnerable Enterprise Gateway versions are absent from manifests and
      images;
    - delimiter-like, newline-containing, duplicate-key-like, and
      document-boundary-like fixture strings are rejected or serialized as data
      without creating extra resources;
    - rendered manifests contain exactly the expected resource kinds;
    - restricted pod security remains present after rendering;
    - service-account manifests have least-privilege permissions.
11. Add a PR body section named `CVE-2026-44182 operator actions` that states:
    - Enterprise Gateway versions before and after;
    - whether users, agents, or systems could pass kernel env values;
    - whether working-directory mirroring or custom kernelspec env passthrough
      was enabled;
    - whether the same deployment is also affected by CVE-2026-44180 or
      CVE-2026-44181;
    - which namespaces, service accounts, PVCs, secrets, and cluster resources
      may have been reachable before the patch;
    - whether pod cleanup, namespace audit, token rotation, image rebuild,
      log review, or secret rotation is required;
    - which validation commands passed.
12. Run available validation: package install, lockfile integrity, unit tests,
    manifest-render tests, duplicate-key parsing tests, Kubernetes RBAC tests,
    policy tests, image build, deployment rendering, SBOM refresh,
    dependency/security scans, and platform smoke tests that do not schedule
    unexpected resources.
13. Use PR title:
    `fix(sec): remediate CVE-2026-44182 in Enterprise Gateway`.

## Stop conditions

- No affected Enterprise Gateway runtime, image, fork, wrapper, process proxy,
  kernel template, or deployment is controlled by this repository.
- Enterprise Gateway is supplied only by another team, managed notebook
  service, or external image; document owner and required fixed version in
  `TRIAGE.md`.
- A fixed Enterprise Gateway version cannot be consumed without a broader
  notebook-platform migration.
- Product requirements intentionally allow untrusted users to inject raw YAML
  into kernel manifests; document the required product/security decision.
- Verification would require multi-document YAML probes, privileged pod
  scheduling, unexpected resource creation, hostPath mounts, or live secret
  access.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Enterprise Gateway, renders manifests with YAML-safe data handling, adds injection tests, reduces Kubernetes blast radius, and documents rollout validation.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, manifest-rendering boundary, service-account reach, required fix, and residual risk.
  • The output must include exact validation commands and must not create privileged resources, expose cluster secrets, or test in production namespaces.

Verification - what the reviewer looks for

  • No controlled lockfile, image, SBOM, package manifest, or deployment target resolves jupyter_enterprise_gateway to a vulnerable version.
  • User-controlled KERNEL_* data is serialized as YAML data and cannot alter object structure, duplicate security fields, or add documents.
  • Tests parse rendered manifests and assert the exact expected object count, kinds, names, namespaces, and security context.
  • Kubernetes admission and RBAC deny privileged or hostPath-mounted kernel workloads from untrusted launch paths.
  • Operator notes cover possible resource injection, pod cleanup, namespace review, token rotation, image rebuilds, and related CVE checks.

Watch for

  • Updating Python requirements while Helm charts, JupyterHub images, kernelspecs, or generated SBOMs still ship an old Enterprise Gateway.
  • Escaping only KERNEL_WORKING_DIR while other KERNEL_* values still enter YAML scalar positions.
  • Tests that assert string output but never parse rendered YAML into objects.
  • YAML loaders that silently accept duplicate keys, multiple documents, or type changes during verification.
  • Admission controls that block privileged pods but still allow hostPath, broad service-account permissions, or extra resource kinds.

References