ZoomEye finds 90,626 publicly indexed Jupyter notebook servers

90,626 hosts matched by an internet-wide fingerprint

A search on the internet-scanning engine ZoomEye matched 90,626 hosts running Jupyter Notebook, according to an analysis published on dev.to on 24 September 2026. The query, executed on 21 September, counted every publicly reachable instance of the software, not only those left wide open, so the figure is best read as the size of the population needing review rather than a confirmed vulnerability count.

What the number actually covers

The dev.to author queried ZoomEye using its "Jupyter Notebook" application fingerprint across all sub-types. Such a fingerprint identifies the software listening on a host but cannot tell whether authentication is configured. The result is therefore an upper bound on exposure: some portion of those hosts will be properly locked down, and some portion will accept any visitor. Determining the split would require checking each host individually, which the analysis does not attempt.

Why an open notebook is a shell for anyone

The core problem sits in the misconfigured portion. Jupyter's interface is not a passive document viewer; it exposes a kernel terminal, so an instance without authentication lets any visitor run commands as the account the notebook server runs under. Those commands inherit that account's permissions and its network position, which can include cloud metadata endpoints — the internal services that hand out credentials and configuration on many cloud platforms.

This is not theoretical. According to the dev.to piece, Jupyter instances have appeared repeatedly in cryptomining and ransomware attack chains. Jupyter's own security documentation states that token authentication has been the default since version 5.0, which means instances accepting anonymous visitors are misconfigured either by accident or deliberately.

The ungoverned asset problem

The author frames the count as evidence of how analysis machines get deployed in practice. Notebooks are often started by individual analysts for data exploration or model training, outside any central asset inventory, bound to all network interfaces, and then forgotten. Each one becomes part of an organisation's attack surface that nobody is actively watching. A population of roughly ninety thousand matching hosts suggests this pattern is common, not a rare edge case.

A defensive checklist

The article closes with concrete steps, drawn from Jupyter's public server documentation:

• Bind notebook servers to localhost or an internal interface, and reach them through SSH tunnels or an authenticated proxy.
• Keep token or password authentication enabled, and never switch it off on shared, multi-user hosts.
• Run the notebook process under a restricted account, never as root.
• Treat any Jupyter instance found publicly reachable in your address space as an active incident, and assume code execution has already taken place.

Why it matters

The difference between sharing a notebook and exposing one comes down to configuration, and the project's defaults have been safe for years. Each unauthenticated instance effectively offers remote code execution with the host's cloud network position attached, turning an analyst's convenience tool into a pivot point for credential theft and lateral movement. The headline figure is an upper bound, but even a small misconfigured share of 90,626 hosts represents a large and ongoing exposure. The cheapest remediation is a configuration audit organisations can run immediately against their own IP space.