Listen to this Post
The vulnerability resides in the prohibited UID/GID feature of Jupyter Enterprise Gateway, which is designed to block kernel launches with UID or GID 0 (root) via environment variables `EG_PROHIBITED_UIDS` and `EG_PROHIBITED_GIDS` (defaulting to "0"). When a kernel request supplies `KERNEL_UID` or `KERNEL_GID` values, the gateway checks if those strings exist within the prohibited strings. However, the check performs a simple substring containment without trimming whitespace. An attacker can supply a value like `”0 “` (a trailing space). Because the prohibited list contains `”0″` (no space), the substring `”0 “` is not found, thus bypassing the validation. Later, when the Kubernetes pod manifest is rendered using Jinja2, the value `”0 “` is parsed as an integer—whitespace is ignored—resulting in a container running with UID/GID 0. This allows unprivileged users (who can create kernels) to launch privileged containers. The issue exists because the validation uses naive string matching while the back-end templating performs strict integer conversion. The documentation explicitly states that root UID/GID should be forbidden, but the implementation fails to normalize inputs. The bypass works on Kubernetes deployments and likely other orchestrators that consume KERNEL_UID/KERNEL_GID. An example malicious request: env:='{"KERNEL_UID": "0 ", "KERNEL_GID": "0 "}'. The gateway returns HTTP 201, and `kubectl exec` shows uid=0(root). Without this bypass, the same request without spaces would return HTTP 403. The flaw is in `container.py` lines 113 and 119, where `prohibited_uids` is a string (e.g., "0") and the user-supplied `KERNEL_UID` is checked with if kernel_uid in prohibited_uids. A trailing space breaks the match. The Jinja2 template `kernel-pod.yaml.j2` lines 35 and 38 apply `int(…)` which strips whitespace. Thus the root pod is created. This is a classic input validation vs. usage mismatch.
DailyCVE Form:
Platform: Jupyter Enterprise Gateway
Version: All prior versions
Vulnerability: Prohibited UID bypass
Severity: Medium (privilege escalation)
date: July 14, 2025
Prediction: July 21, 2025
What Undercode Say:
Valid request (blocked)
xh http://enterprise-gateway.bdawg.svc.cluster.local:8888/api/kernels \
name=python_kubernetes env:='{"KERNEL_POD_NAME":"bdawg", "KERNEL_UID": "0", "KERNEL_GID": "0"}'
Response: 403 Forbidden
Bypass using trailing space (successful)
xh http://enterprise-gateway.bdawg.svc.cluster.local:8888/api/kernels \
name=python_kubernetes env:='{"KERNEL_POD_NAME":"bdawg", "KERNEL_UID": "0 ", "KERNEL_GID": "0 "}'
Response: 201 Created
Verify root inside pod
kubectl exec -it pod/bdawg -- bash
id uid=0(root) gid=0(root)
How Exploit:
- Identify a reachable Jupyter Enterprise Gateway API endpoint (e.g.,
/api/kernels). - Craft a kernel creation request with `KERNEL_UID` and/or `KERNEL_GID` set to `”0 “` (or any prohibited ID followed by whitespace).
- Optionally add a `hostPath` volume mount to the kernel pod specification for container escape.
- Send request; gateway bypasses substring check and creates pod as root.
- Execute arbitrary commands inside the privileged container, then break out to the worker node via mounted host filesystem (e.g., write crontab or SSH keys).
Protection:
- Upgrade to a patched version (when available) that trims whitespace or uses integer comparison instead of substring containment.
- As a temporary mitigation, modify `EG_PROHIBITED_UIDS` to include values with trailing spaces (e.g.,
"0,0 "), though this is fragile. - Restrict API access to trusted users only; use network policies and authentication.
- Avoid granting users the ability to define custom volume mounts or privileged security contexts.
- Monitor kernel creation requests for unusual
KERNEL_UID/KERNEL_GIDpatterns (e.g., numeric values with whitespace).
Impact:
Allows unprivileged users to launch Jupyter kernels as root on Kubernetes clusters (and potentially other orchestrators). This increases attack surface, enables container escapes via hostPath mounts, and can lead to full compromise of worker nodes and the entire Kubernetes cluster. Repeated exploitation can pivot across nodes, exfiltrate secrets, and disrupt workloads.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
