Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

CVE-2026-114135 — jupyter-server

HIGHFix: jupyter-server/jupyter_server@35ffe5d

CVE-2026-114135 is a high-severity (CVSS 8.8) CWE-862 vulnerability in jupyter-server. A fix is available for jupyter-server — see the affected versions and patch details below.

Jupyter Server: Gateway WebSocket handler bypasses kernel execute authorization

Also known asGHSA-354v-3q48-cv69
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs31th percentile — riskier than 31% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-114135 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,415 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍jupyter-server

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Jupyter Server's gateway WebSocket handler checks that a user is authenticated, but it does not ask the configured Authorizer whether that user may execute kernels.

In Jupyter Server 2.0.0 through 2.5.0, enabling GatewayClient.url automatically replaced the normal kernel channel handler with this gateway-specific handler. An authenticated user who is denied the execute action on the kernels resource can therefore still open a kernel channel and send messages to the upstream kernel.

Details

The normal handler performs the expected authorization check before creating the WebSocket connection:

https://github.com/jupyter-server/jupyter_server/blob/v2.5.0/jupyter_server/services/kernels/websocket.py#L39-L47

The gateway handler only checks current_user and then opens the upstream channel. It never calls authorizer.is_authorized(...):

https://github.com/jupyter-server/jupyter_server/blob/v2.5.0/jupyter_server/gateway/handlers.py#L49-L75 https://github.com/jupyter-server/jupyter_server/blob/v2.5.0/jupyter_server/gateway/handlers.py#L87-L98

Gateway mode selected that handler automatically by replacing handlers with matching routes:

https://github.com/jupyter-server/jupyter_server/blob/v2.5.0/jupyter_server/serverapp.py#L437-L446

PR #1261 stopped replacing the normal handler and routed gateway traffic through GatewayWebSocketConnection instead. This appears to have fixed the default gateway configuration in 2.6.0, although the deprecated handler is still present in current releases and can still be registered directly.

https://github.com/jupyter-server/jupyter_server/pull/1261

Code-level validation

  1. Configure a custom Authorizer that returns false for execute on kernels for a regular authenticated user.
  2. Configure GatewayClient.url on Jupyter Server 2.0.0-2.5.0.
  3. The normal KernelWebsocketHandler would reject that user with 403 in pre_get.
  4. Gateway mode replaces it with WebSocketChannelsHandler. Its authenticate method only rejects anonymous users, and get proceeds to the upstream gateway without an authorization decision.

Impact

This is a missing authorization check, not an authentication bypass. It matters in deployments that use a restrictive custom Authorizer and Jupyter Gateway/Enterprise Gateway. A read-only or otherwise limited authenticated user can cross the intended authorization boundary and obtain kernel execution, with access to data and credentials available to that kernel.

Affected versions

  • Default gateway configuration: 2.0.0 through 2.5.0
  • 2.6.0 and later: the default path uses the authorized standard handler, but manually registering the deprecated jupyter_server.gateway.handlers module still exposes the old behavior.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIjupyter-server≥ 2.0.0&&< 2.6.02.6.0pip install --upgrade 'jupyter-server==2.6.0'

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for jupyter-server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update jupyter-server to 2.6.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-114135 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### Summary Jupyter Server's gateway WebSocket handler checks that a user is authenticated, but it does not ask the configured Authorizer whether that user may execute kernels. In Jupyter Server 2.0.0 through 2.5.0, enabling GatewayClient.url automatically replaced the normal kernel channel handler with this gateway-specific handler. An authenticated user who is denied the `execute` action on the `kernels` resource can therefore still open a kernel channel and send messages to the upstream kernel. ### Details The normal handler performs the expected authorization check before creating the
O3 Security · Impact-Aware SCA

Is CVE-2026-114135 in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2026-114135: jupyter-server — Fixed in 2.6.0