Less than ten hours. That is how long it took for attackers to weaponise a freshly disclosed vulnerability in Marimo, an open-source Python notebook framework popular with data scientists and AI researchers. No public exploit code existed. The attacker simply read the advisory and built a working exploit from the description.
The flaw, tracked as CVE-2026-39987, carries a CVSS score of 9.3 and allows pre-authentication remote code execution. Any attacker who can reach a vulnerable Marimo instance gets a full PTY shell. No credentials required. If you are unfamiliar with how CVE scoring works, a 9.3 sits firmly in the critical range and warrants immediate attention.
How the vulnerability works
Marimo exposes several WebSocket endpoints. Every one of them, with a single exception, calls validate_auth() before accepting a connection. The exception is /terminal/ws. This endpoint only checks the running mode and whether the platform supports a terminal. Authentication is never verified.
The consequence is severe. Connect to the endpoint, get a PTY, run commands as the user owning the notebook process. That is the entire exploit chain.
All versions of Marimo up to and including 0.20.4 are affected. The fix landed in version 0.23.0, which adds the missing authentication check. Organisations running anything older should treat this as urgent.
From disclosure to active exploitation in under ten hours
The Sysdig Threat Research Team observed the first in-the-wild exploitation attempt nine hours and forty-one minutes after the advisory was published. There was no public proof-of-concept at that point. The attacker had read the disclosure, identified the unprotected endpoint, and written working exploit code in the time it takes most security teams to convene a triage meeting.
What followed was methodical. The attacker connected to /terminal/ws, received an interactive shell, and began manually exploring the compromised environment. A complete credential theft operation finished in under three minutes. Fast. Hands-on. Quiet.
This is what modern opportunistic exploitation looks like. Disclosure is no longer a head start. It is a starting gun. The compressed timeline reinforces the importance of knowing which CVEs actually get exploited, rather than processing every advisory in arrival order.
NKAbuse and the abuse of decentralised protocols
Since initial exploitation, the vulnerability has been used to deploy NKAbuse, a multi-platform malware family that uses the NKN protocol for command-and-control traffic. NKN, short for New Kind of Network, is a legitimate blockchain-based peer-to-peer networking protocol.
That is precisely what makes it useful to attackers. Traditional blocklists based on IP addresses or known malicious domains do not work against a C2 channel that rides on a decentralised P2P network. The traffic looks like normal NKN traffic because, in a technical sense, it is. Defenders accustomed to writing firewall rules against a known set of C2 servers face a fundamentally different problem.
CISA action and public exploit code
CISA added CVE-2026-39987 to its Known Exploited Vulnerabilities catalogue shortly after exploitation was confirmed. Federal Civilian Executive Branch agencies were ordered to remediate by 7 May 2026. Private sector organisations should treat the KEV listing as a strong signal regardless of regulatory obligation.
A detection and exploitation proof-of-concept is now publicly available on GitHub. The repository includes a Python detection script and an Nmap NSE script for network-wide scanning. This lowers the bar significantly. Anyone capable of running Nmap can now find vulnerable Marimo instances at scale.
The wider problem: notebooks as exposed infrastructure
The Cloud Security Alliance has flagged this incident as emblematic of a broader pattern. Data science and AI toolchains frequently run publicly accessible notebook servers without authentication. Marimo. Jupyter. Others. The assumption is that these tools are "internal only" and therefore do not need TLS or access controls.
That assumption rarely survives contact with reality. Notebook servers end up exposed on cloud developer environments, bastion hosts, VPN-accessible subnets that are not as isolated as their owners believe, and sometimes the open internet. Each unauthenticated notebook is a potential RCE waiting for the next CVE. Each one expands the organisation's attack surface in ways that traditional asset inventories often miss.
Data science teams move fast. Security configurations frequently lag behind. The Marimo incident shows the cost of that gap. The pattern of running unauthenticated notebook servers is an industry-wide problem affecting Jupyter and other similar tools, not a Marimo-specific failure. Jupyter, the most widely deployed notebook server of all, shares exactly the same exposure pattern whenever it is deployed without authentication on networks that turn out to be less isolated than assumed.
What to do now
Update to Marimo 0.23.0 or later. Immediately. This is the only complete fix.
If immediate patching is not possible, ensure that Marimo instances are not reachable from untrusted networks. Place them behind a reverse proxy that enforces authentication. Restrict the /terminal/ws endpoint at the network layer. Treat any internet-facing notebook server as compromised until proven otherwise.
Hunt for signs of exploitation. Unusual outbound connections, particularly to NKN-related infrastructure, are worth investigating. Shell processes spawned by the Marimo notebook user, unexpected credential file access, and new SSH keys are all useful indicators of compromise. The publicly available Nmap NSE script can also be used defensively to identify vulnerable instances within your own estate before someone else does.
The Marimo case is a reminder that vulnerability management timelines have collapsed. Nine hours and forty-one minutes. That is the window between disclosure and exploitation for a critical flaw in a tool used widely across AI and data science teams. Organisations still operating on a thirty-day patching cadence for "internal" tools need to revisit that assumption.
Frequently asked questions
Is Marimo still safe to use?
If you are running version 0.20.4 or earlier, you are exposed to pre-authentication remote code execution with a CVSS score of 9.3. Marimo remains safe to use provided it is updated to version 0.23.0 or later, which adds the missing authentication check on the /terminal/ws endpoint. If you are running anything older and the server has been reachable from a network you do not fully control, you should assume compromise rather than just patch and move on. Update immediately, rotate any credentials that lived on or near the host, and review process and outbound connection history for the period the instance was exposed.
How does NKAbuse use NKN for command-and-control?
NKAbuse routes its C2 traffic through NKN, a legitimate decentralised blockchain-based peer-to-peer networking protocol, rather than through a fixed set of attacker-controlled servers. Because the traffic genuinely is NKN traffic at the protocol level, blocklists based on IP addresses or malicious domains are effectively useless against it. This is a real shift for defenders who built their detection strategy around known-bad network indicators. The practical response is to focus on host-side signals, such as shell processes spawned by the Marimo user and unexpected credential file access, and to flag any NKN-related outbound connections from servers that have no business speaking that protocol.
Are Jupyter notebooks affected by the same issue?
The attacker just needs an unauthenticated WebSocket terminal endpoint, and CVE-2026-39987 is specific to Marimo's /terminal/ws, so Jupyter is not vulnerable to this particular flaw and has its own separate authentication model and CVE history. The wider pattern, however, very much applies. The Cloud Security Alliance flagged this incident precisely because unauthenticated notebook servers, whether Marimo, Jupyter or something else, keep ending up on cloud dev environments, bastion hosts and VPN subnets that are less isolated than their owners assume. Treat every notebook server as production infrastructure, put authentication, TLS and network restrictions in front of it, and include them in your normal asset inventory rather than the "internal tools" category that nobody patches on time.
