Jupyter Server: gateway kernel channel skips the execute authorization check, letting restricted users run code

Impact

On a Jupyter Server configured with GatewayClient.url - the usual shape when notebooks are fronted by a gateway so kernels land on GPU nodes - the kernel websocket handler is swapped for WebSocketChannelsHandler, which authenticates the user but never asks the configured Authorizer whether the execute action on the kernels resource is allowed. Any authenticated user who was supposed to be read-only can open an upstream kernel channel and get real code execution inside the kernel. That means whatever the kernel process can see: mounted datasets, the GPUs assigned to it, service account tokens and cloud credentials in its environment, plus the ability to disrupt other users' work on the same node. Fixed for the default gateway configuration in 2.6.0, but the bypass remains on 2.6.0 and later if a deployment still manually registers the deprecated jupyter_server.gateway.handlers module.

Who can reach it

Network access to the Jupyter Server with valid credentials for any account, including one the Authorizer is configured to restrict to read-only. No admin rights needed.

What to do

Upgrade jupyter_server to 2.6.0 or later and restart the server process; sessions are interrupted but nodes do not need draining. Separately, audit the configuration for manual registration of jupyter_server.gateway.handlers - on 2.6.0+ that deprecated module still omits the authorization decision, so remove it rather than relying on the version bump. If you depend on Authorizer rules to keep users out of kernels, treat those rules as not enforced until both steps are done.

References

Related entries

• nbconvert: notebook output metadata filename escapes output_files_dir, writing files anywhere the converter can reachCVE-2026-114140 · Jupyter nbconvert (ExtractOutputPreprocessor output filename handling)High
• vLLM: forged shared-memory handles in multimodal kwargs reach pickle.loads on workersCVE-2026-115912 · vLLM (shared-memory multimodal feature cache)High
• vLLM: attacker-supplied X-Request-Id makes a prefill worker ZMQ-connect out, leaking NCCL id and KV cacheCVE-2026-116176 · vLLM P2pNcclConnector (decode address from X-Request-Id header)High
• OpenShift AI dashboard: incorrect network binding lets an in-cluster actor impersonate any user with an arbitrary tokenCVE-2026-16745 · Red Hat OpenShift AI odh-dashboard (network binding / token handling)High
• Langflow: incomplete filtering of Docker volume and device arguments exposes host files from a flowCVE-2026-17626 · IBM Langflow OSS (Docker-based MCP server argument filtering)High
• OpenShift AI training-operator: namespace edit/admin users escalate to host filesystem access via crafted training jobsCVE-2026-18982 · Red Hat OpenShift AI training-operator (ClusterRole aggregation + PodTemplateSpec passthrough)High