Does Jupyter Server Gateway Bypass Let Users Run Code?

The short version

• Enabling GatewayClient.url in older versions swaps the handler without checking authorisation.
• This allows kernel execution despite explicit denial rules set by administrators.
• The issue persists in version 2.6.0 if the deprecated gateway module is manually registered.

The details

Jupyter Server acts as the backend for various web applications. According to the NVD record for CVE-2026-114135, versions ranging from 2.0.0 until 2.6.0 contain a significant authorisation flaw. When administrators enabled the GatewayClient.url setting, the system replaced the standard KernelWebsocketHandler with WebSocketChannelsHandler. While this new handler did authenticate the user, it failed to call the authorizer.is_authorized function for execute actions on kernel resources. This omission meant that a restricted, authenticated user could open an upstream kernel channel.

Consequently, they could obtain kernel execution privileges. This occurred even when the configured Authorizer explicitly denied that specific action. The exposure grants access to data and credentials available to the kernel. It also permits modification or disruption of the kernel environment itself. The default gateway configuration was fixed in version 2.6.0. However, the same bypass remains possible in version 2.6.0 and later if a deployment manually registers the deprecated jupyter_server.gateway.handlers module. Its handler still omits the configured kernel-execute authorisation decision.

The context

The weakness is classified under CWE-862. This category covers incorrect default permissions. The vulnerability is rated as high severity with a CVSS score of 8.8. It applies to environments where Jupyter Server is deployed with gateway features enabled. Teams using older versions are directly exposed to this logic error in the handling of websocket connections. The flaw highlights how swapping components can inadvertently bypass established security controls.

Next steps

Organisations should verify their current Jupyter Server version. If running any version before 2.6.0, an update is required. For those on version 2.6.0 or later, check for manual registrations of the deprecated gateway module. Remove any custom registrations of jupyter_server.gateway.handlers to ensure proper authorisation checks occur. No other fixes have been confirmed yet for the deprecated module path.

What defenders should look for

Teams usually monitor for unexpected websocket connections to kernel endpoints. Check whether authenticated users are initiating execute actions that their roles should not permit. Look for logs showing successful kernel launches from users with restricted privileges. Inspect authorisation logs for missing checks on execute requests. If anomalies appear, isolate the affected server immediately. Review configurations for any manual handler registrations that might bypass standard controls. Verify that all gateway settings align with current security policies.

What to do and how to stay safe: Jupyter Server

• Audit Jupyter Server installations to identify versions prior to 2.6.0.
• Review configuration files for any manual registration of the deprecated gateway handlers module.
• Monitor logs for websocket connections that initiate kernel execution without corresponding authorisation records.
• Restrict network access to Jupyter Server interfaces once the vendor provides an update.

Step-by-step guide: How Virtual Patching Works: The Mechanics Behind Inline Protection

General security guidance from the Honeypot Daily newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Jupyter Server are affected by this vulnerability?

Versions from 2.0.0 until 2.6.0 are affected. Version 2.6.0 is also vulnerable if the deprecated module is manually registered.

What is the severity rating for CVE-2026-114135?

The NVD rates the severity as high, with a CVSS score of 8.8.

Can a restricted user execute code through this flaw?

Yes, a restricted authenticated user can obtain kernel execution despite the configured Authorizer denying the action.