Marimo RCE flaw exploited in under 10 hours after disclosure, researchers say

Attackers began exploiting a critical Marimo remote code execution flaw less than 10 hours after its public disclosure, according to Sysdig Threat Research Team. The bug, tracked as CVE-2026-39987 and GitHub advisory GHSA-2679-6mx9-h9xc, affects Marimo’s terminal WebSocket endpoint and can let an unauthenticated attacker gain an interactive shell on exposed instances.

The timeline is unusually short even by current standards. Sysdig says the first exploitation attempt hit its honeypot environment 9 hours and 41 minutes after the advisory appeared on GitHub, and the attacker stole credentials within minutes of gaining access.

BEST SPRING 2026 DEALS

Editor's Choice

Private Internet Access

Access content across the globe at the highest speed rate.

70% of our readers choose Private Internet Access

70% of our readers choose ExpressVPN

ExpressVPN

Browse the web from multiple devices with industry-standard security protocols.

Nord VPN

Faster dedicated servers for specific actions (currently at summer discounts)

That makes this more than just another open source bug disclosure. It shows how quickly threat actors can move from reading a technical advisory to building a working exploit, even when no public proof of concept is available yet.

What the Marimo vulnerability does

According to the GitHub advisory, the vulnerable /terminal/ws endpoint accepts WebSocket connections without enforcing authentication. Other Marimo WebSocket endpoints validate auth before accepting a connection, but this one skipped that check.

That gap turns a single WebSocket connection into a full pseudo-terminal shell. In practice, that means an attacker can run arbitrary system commands with the privileges of the Marimo process, with no login required.

GitHub’s advisory database lists the issue as critical with a CVSS v4.0 score of 9.3. The advisory says patched version 0.23.0 fixes the problem, while vulnerable versions fall below 0.23.0, with the detailed write-up specifically calling out Marimo 0.20.4 and earlier in the original disclosure context.

How the attack unfolded

Sysdig says the first observed exploitation attempt came from IP address 49.207.56.74 at 07:31 UTC on April 9, 2026, after the advisory went live at 21:50 UTC on April 8. By 07:44 UTC, the attacker had already exfiltrated a .env file containing credentials.

The researchers say no public exploit code appeared on GitHub or major exploit repositories at the time of the first attack. They believe the attacker built the exploit directly from the advisory, which already named the vulnerable endpoint and explained the missing authentication check.

Sysdig also says the attacker did not need a complex payload. Once connected, the intruder used the terminal access to explore the environment manually and harvest sensitive secrets, including cloud credentials stored in local files.

Why this bug is especially dangerous

Marimo is not the biggest notebook platform on the market, but the project still has around 20,000 GitHub stars, which gives it a meaningful footprint among developers and data teams. Sysdig says the speed of this attack suggests threat actors now watch advisory feeds broadly, not just for massive enterprise platforms.

Notebook platforms also tend to hold valuable secrets. Sysdig notes that these environments often contain database credentials, API keys, cloud tokens, and access to datasets, which means a single exposed instance can open the door to broader infrastructure compromise.

Another factor is ease of exploitation. The advisory shows that a single unauthenticated WebSocket connection to /terminal/ws can be enough to get shell access, which sharply lowers the barrier for attackers.

Key facts at a glance

What admins should do now

• Update Marimo to version 0.23.0 or later immediately.
• Block external access to /terminal/ws and avoid exposing notebook platforms directly to the internet.
• Audit .env files and environment variables on any internet-exposed Marimo instance.
• Rotate AWS keys, API tokens, database passwords, and other secrets that may have been exposed.
• Review logs for suspicious WebSocket connections and activity from known indicators, including 49.207.56.74.

FAQ