CVE-2026-114135 in Jupyter Server
Summary
by MITRE • 10/21/2026
Jupyter Server is the backend for Jupyter web applications. From 2.0.0 until 2.6.0, enabling GatewayClient.url replaced the normal KernelWebsocketHandler with WebSocketChannelsHandler, which authenticated the user but did not call authorizer.is_authorized(...) for the execute action on the kernels resource. A restricted authenticated user could therefore open an upstream kernel channel and obtain kernel execution despite the configured Authorizer denying that action, exposing data and credentials available to the kernel and permitting modification or disruption of the kernel environment. The default gateway configuration is fixed in version 2.6.0. In 2.6.0 and later, the same authorization bypass remains possible when a deployment manually registers the deprecated jupyter_server.gateway.handlers module, because its handler still omits the configured kernel-execute authorization decision.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Jupyter Server versions from 2.0.0 through 2.6.0 represents a critical authentication bypass within the gateway architecture that fundamentally undermines access control mechanisms designed to protect computational resources. This flaw specifically manifests when the GatewayClient.url configuration is enabled, which triggers a substitution of the standard KernelWebsocketHandler with WebSocketChannelsHandler. While this handler correctly performs user authentication to verify identity, it fails to invoke the configured authorizer's is_authorized method for the execute action on kernels resources. Consequently, any authenticated user, regardless of their assigned permissions or restrictions within the Jupyter environment, can establish an upstream kernel channel and initiate code execution without proper authorization checks. This discrepancy creates a significant security gap where identity verification does not translate into permission enforcement, allowing restricted users to bypass administrative controls intended to limit their operational scope.
The operational impact of this vulnerability is severe due to the privileged nature of Jupyter kernels in typical deployment scenarios. Kernels often operate with elevated privileges relative to the web application and may have access to sensitive data stores, internal network services, or credential files that are not accessible through standard notebook interfaces. By exploiting this authorization bypass, an attacker can execute arbitrary code within the kernel environment, leading to potential data exfiltration of confidential information stored in memory or on disk associated with the session. Furthermore, the ability to modify the kernel environment allows for persistent compromise, including the installation of malicious packages, alteration of system configurations, or disruption of services running under the same user context. This effectively neutralizes any security policies implemented via Jupyter's authorizer module, rendering role-based access controls ineffective against authenticated users who leverage this specific gateway configuration path.
From a technical classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and specifically relates to authorization bypasses in web applications where authentication succeeds but authorization checks are omitted for critical actions. In the context of the MITRE ATT&CK framework, this behavior corresponds to techniques involving unauthorized access to resources or privilege escalation within a specific environment, such as T1078 Valid Accounts when combined with lateral movement if kernel execution allows interaction with other systems. The root cause lies in the architectural decision to use WebSocketChannelsHandler for gateway connections without ensuring that all security middleware and authorization hooks are consistently applied across different handler implementations. This inconsistency highlights the importance of rigorous code review processes, particularly when modifying or replacing core handlers in complex web frameworks like Jupyter Server.
Mitigation strategies must address both immediate remediation and long-term architectural fixes. For deployments running versions 2.0.0 through 2.5.x, upgrading to version 2.6.0 is the primary recommendation as it corrects the default gateway configuration behavior. However, administrators must remain vigilant regarding custom configurations; even in patched versions, manually registering the deprecated jupyter_server.gateway.handlers module reintroduces the vulnerability because that legacy handler continues to omit the necessary kernel-execute authorization decision. Therefore, organizations should audit their Jupyter Server deployments for any manual registration of this deprecated module and remove such configurations entirely. Additionally, implementing network-level controls such as restricting direct WebSocket access from untrusted networks can provide a defense-in-depth layer while internal codebases are updated. Regular security assessments focusing on authentication versus authorization consistency in web application handlers will help prevent similar oversights in future development cycles.