Security bugs are often described in abstract language like "authentication bypass" or "remote code execution," but sometimes a vulnerability is so direct that the risk is obvious immediately. CVE-2026-39987 is one of those cases.
This flaw affects marimo, an open-source reactive Python notebook platform used for data analysis, machine learning, research, dashboards, and lightweight Python apps. marimo notebooks are stored as plain Python files and can be used both as notebooks and as interactive applications, which makes the platform attractive to developers, data scientists, and researchers.
The issue is serious because a terminal WebSocket endpoint in marimo, /terminal/ws, failed to enforce authentication before accepting connections. In practice, that meant an unauthenticated attacker could connect to the service and gain an interactive shell on the underlying host. Public advisories describe this as a pre-authentication remote code execution flaw, and the CNA score shown in the NVD entry is CVSS v4.0 9.3 Critical.
What marimo is, and why this matters
If you have never used marimo, the easiest way to think about it is as a modern Python notebook environment in the broad orbit of Jupyter, but more reactive and more app-oriented. When a user changes code or interacts with UI controls, dependent cells update automatically. That makes it well suited for live data work and interactive notebooks.
When those notebooks are deployed or shared over a network, marimo stops being just a developer tool and starts behaving like a service that has to be secured like any other application server. That shift matters here. A local notebook on a laptop is one thing. A network-exposed notebook service with terminal access is something very different.
The vulnerability in plain English
At the center of CVE-2026-39987 is marimo's /terminal/ws endpoint.
According to public reporting, this endpoint exposed an interactive terminal without proper authentication checks, allowing connections from unauthenticated clients. Once connected, the attacker could get access to a full interactive shell running with the same privileges as the marimo process.
That is what makes this flaw especially dangerous. This was not a narrow command injection with limited reach. It was a direct path to an interactive shell over the network.
Why this bug is so severe
Some RCE bugs require special conditions, user interaction, or elaborate exploitation chains. This one did not. BleepingComputer reports that attackers were able to move from disclosure to real exploitation extremely quickly, because the route was simple to understand and test. The article says attackers started exploiting the flaw about 10 hours after public disclosure, based on Sysdig's observations.
That fast turnaround tells you two things:
- First, the vulnerability was easy for attackers to operationalize.
- Second, internet-exposed vulnerable instances were immediately at risk once details became public.
BleepingComputer also reports that within the first 12 hours after disclosure, 125 IP addresses began reconnaissance activity tied to the issue.
What attackers actually did
One of the most useful additions from the BleepingComputer reporting is that it goes beyond the vulnerability description and shows how attackers behaved in the wild.
According to the article, attackers first validated exploitation by connecting to /terminal/ws and running a short command sequence to confirm remote code execution. They then reconnected and performed hands-on reconnaissance using basic commands like pwd, whoami, and ls, followed by attempts to navigate directories and inspect SSH-related locations.
After that, the attackers shifted quickly to credential theft. The report says they targeted .env files, extracted environment variables, and looked for cloud credentials, application secrets, and SSH keys. The credential access phase reportedly took less than three minutes.
That detail is important because it shows what defenders should focus on after exposure: not just whether someone got shell access, but whether secrets were harvested almost immediately.
What makes the observed activity notable
The reporting also suggests that the exploitation was not purely spray-and-pray automation. BleepingComputer says the observed attacker appeared to behave like a methodical hands-on operator, returning for a second exploitation session about an hour later and focusing on high-value data rather than noisier follow-on actions like persistence, cryptomining, or backdooring.
That changes the response mindset a bit. If a vulnerable marimo instance was exposed, defenders should not assume a quick opportunistic probe and move on. They should consider the possibility of targeted secret collection, especially around:
.envfiles- application configuration
- cloud credentials
- SSH keys
- tokens stored in environment variables
Who was actually at risk
BleepingComputer notes that marimo disclosed the flaw on April 8, 2026, and released version 0.23.0 to address it. The developers reportedly said the issue affects users who deployed marimo as an editable notebook and those who exposed marimo to a shared network using --host 0.0.0.0 while in edit mode.
The most exposed users were those running marimo in a way that made notebook editing reachable over a network, especially without a stronger auth layer in front of it. Local-only use is a very different risk profile from shared or internet-facing edit-mode deployments.
The version detail defenders should handle conservatively
BleepingComputer says the flaw affects marimo 0.20.4 and earlier and notes that 0.23.0 was released to fix it. Because public vulnerability metadata around affected ranges can sometimes lag or be inconsistent early on, the safest operational approach is straightforward: if you are running an older marimo deployment and especially anything network-exposed, move to 0.23.0 or later rather than trying to split hairs over exactly which intermediate versions may or may not be exposed.
What defenders should do now
Users are advised to:
- upgrade to version 0.23.0 immediately
- monitor WebSocket connections to
/terminal/ws - restrict external access using a firewall
- rotate any exposed secrets
- if patching cannot happen immediately, block or disable access to
/terminal/wsentirely
That last point matters. Blocking the vulnerable endpoint is not the same as a real fix, but it is a meaningful stopgap when response teams need to buy time.
The bigger lesson
CVE-2026-39987 is not just a marimo story. It is a very clear reminder that once a developer tool becomes network-accessible, every terminal feature, collaboration feature, WebSocket route, and background service becomes security-critical.
The lesson is simple: auth must be enforced everywhere, not just on the main application paths. One overlooked route can undo every protection users thought they had.
And as this case shows, attackers do not need much time to take advantage of that kind of mistake.
Reference: CVE-2026-39987 on NVD