Marimo RCE Vulnerability is Being Exploited Right Now

Is the Marimo RCE vulnerability under active exploitation on April 13, 2026?

Yes. CVE-2026-39987 affects Marimo 0.20.4 and earlier. Attackers began exploiting a critical flaw in the Marimo open-source reactive Python notebook platform within just 10 hours of its public disclosure.

The issue allows unauthenticated remote code execution through the /terminal/ws endpoint, and the fix is available in Marimo 0.23.0. Any exposed notebook instance should be patched and reviewed immediately.

Technical overview

Item	Details
Vulnerability	CVE-2026-39987
Product	Marimo reactive Python notebook
Severity	Critical
Score	CVSS 9.3
Attack type	Pre-auth RCE
Root cause	Missing authentication on /terminal/ws
Affected versions	0.20.4 and earlier
Fixed version	0.23.0
Observed activity	Active exploitation
Typical attacker goal	Shell access and credential theft

The core bug is ugly in a very simple way. According to the GitHub security advisory, the terminal WebSocket endpoint did not validate authentication before granting access, while other WebSocket paths did. That mismatch is what turns a normal feature into a remote entry point.

Security reporting and vendor release notes line up on the scope. The highest-risk cases are editable notebook deployments exposed to the public internet or environments bound to 0.0.0.0 where the built-in authentication was treated as the only control.

Our Technical Analysis

What makes the Marimo RCE vulnerability more serious than a routine open-source bug is not just the score.

It is the shape of the target. Notebook platforms often sit close to the things that matter most: cloud credentials, API tokens, SSH keys, test datasets, and deployment secrets. Once an attacker gets code execution there, the blast radius can jump fast.

That is why this story matters differently to different readers. A solo developer might think, “It is only my notebook server.”

A company sees something else: a soft spot in the AI and data pipeline, often connected to Git repos, model artifacts, S3 buckets, internal APIs, and secret-rich .env files. Same flaw. Very different consequences.

There is another lesson here. We are watching the time-to-exploit collapse in public. Sysdig observed the first exploitation attempt 9 hours and 41 minutes after the advisory went public, with credential theft happening minutes later.

That is not a leisurely patch cycle anymore. That is attackers reading advisories over coffee and acting before some teams finish morning triage.

So ask the uncomfortable question. If your notebook stack is visible from the internet, do you know that before an attacker does?

And if you rely on built-in auth alone, was that ever a strong enough assumption for something that can spawn a shell?

What Actually Broke

The Marimo RCE vulnerability comes from a missing auth check on the /terminal/ws endpoint.

The official advisory says the path could accept a WebSocket connection and hand the attacker a full PTY shell without validating credentials first.

In practical terms, that means arbitrary command execution from outside the app’s trust boundary.

That detail matters because it explains both the severity and the speed of weaponization. Attackers did not need a long exploit chain.

They needed a reachable target and an endpoint that trusted the wrong thing. Public detection content now exists as well, including a Nuclei template that checks the endpoint for signs of shell execution.

Defenders can use that as a signal that scanning and copycat activity will likely spread.

The vendor’s release notes also clarify who is most exposed: notebook deployments in edit mode, published to the public internet or reachable on a shared network, especially where teams assumed Marimo’s built-in auth was the only line of defense.

That narrows the exposure story, but it should not make anyone relax too much. Internal-only services get exposed all the time through reverse proxies, temporary firewall changes, test tunnels, and stale cloud rules.

Lab Observation

We did not run a live exploit against any public target for this article. That would be reckless. What we did do was review the advisory details, the vendor release notes, and the publicly published detection logic to understand how quickly this can move from theory to compromise.

What stood out was how little friction exists once the endpoint is reachable. When a vulnerable service exposes a terminal channel without proper auth, attackers do not need a fancy post-exploitation framework to get started.

A shell is enough. A few minutes later they are checking environment files, local keys, cloud tokens, and scripts. That behavior matches the credential-theft sequence observed by Sysdig.

We also noticed something defenders often miss. Teams focus on patching the application binary, but they forget the side effects.

If a notebook instance was exposed and vulnerable, you should not stop at upgrading Marimo. You should assume secrets on that host may have been read already.

Why This Matters

The Marimo RCE vulnerability is not only a product issue. It is an AI toolchain issue. That is the real story.

Notebook systems tend to live in messy, practical environments. Developers store convenience tokens. Data scientists keep local copies of datasets.

Service accounts get added “temporarily” and then survive for months. The path from notebook compromise to cloud account misuse is often shorter than leadership expects.

For home lab users or small teams, the risk is immediate account theft and host compromise. For businesses, it can become a wider incident involving source code exposure, data access, and unauthorized infrastructure activity.

One exposed notebook can become the first domino. That is why this story deserves more than a simple “please update now” banner.

And here is the awkward part. Vulnerabilities like this are easy to underestimate because the product is not as mainstream as a big enterprise appliance. Attackers do not care. If the server gives them a shell and the host contains useful secrets, it is valuable enough.

How to Protect Your System

1. Upgrade Marimo now

The vendor says 0.23.0 contains the security fix for CVE-2026-39987. If you are on 0.20.4 or earlier, move immediately.

Typical update command:

python -m pip install --upgrade marimo==0.23.0

If you manage it through requirements files, pin the fixed release and redeploy:

echo "marimo==0.23.0" >> requirements.txt

pip install -r requirements.txt

If you are using containers, rebuild from a clean base image and redeploy the service. Do not assume a rolling restart alone is enough if the old container might have been accessed.

2. Find exposed instances fast.

Start with the obvious checks. Look for internet-facing notebook services, reverse proxies that forward traffic to Marimo, and hosts running with --host 0.0.0.0. The release notes call out exactly that exposure pattern.

Quick hunting ideas:

ss -lntp | grep -E "2718|marimo"

ps aux | grep marimo

grep -R "marimo" /etc/nginx /etc/caddy /etc/traefik 2>/dev/null

Cloud and edge teams should also search for open security groups, public load balancers, and stale dev subdomains. A service marked “temporary” in February can still be live in April. That happens more than anyone likes to admit.

3. Block access before patching, if needed

If you cannot patch in the next few minutes, reduce exposure first. Restrict inbound access by IP, remove public routes, or shut the service down until maintenance is complete. A broken notebook is annoying. A compromised notebook is expensive.

Example with UFW:

sudo ufw deny 2718/tcp

sudo ufw allow from <trusted-ip>/32 to any port 2718 proto tcp

Or with a cloud firewall, move the rule from 0.0.0.0/0 to a short allowlist. This is not the final fix. It is just the fastest brake pedal.

4. Assume secrets may be exposed.

Reports on active exploitation point to credential theft, including .env files and other sensitive material. If the host were reachable and vulnerable, rotate what matters.

Start with:

• Cloud access keys

• Database passwords

• API tokens

• Git credentials

• SSH keys

• Internal service secrets

This is where many teams stumble. They patch first, feel relieved, and move on. But a patch does not revoke a stolen token.

5. Check logs and process history

Look for suspicious WebSocket requests to /terminal/ws, shell activity tied to the service account, and unusual file reads. If you have EDR, review process trees. If not, use what the host gives you.

Useful commands:

grep -R "/terminal/ws" /var/log 2>/dev/null

journalctl -u <service-name> --since "2026-04-08"

find /home -name ".env" -type f -printf "%TY-%Tm-%Td %TT %p\n" 2>/dev/null | sort

last -a

Also check outbound traffic. An attacker grabbing secrets often tries to exfiltrate them quickly, not linger for days.

6. Rebuild if compromise is plausible.

If the server was exposed and you cannot rule out exploitation, a clean rebuild is often the smarter path. Upgrade the package, rotate secrets, redeploy from trusted images, and verify startup config. The longer you try to “clean up” a maybe-compromised dev host in place, the messier it gets.

Usual Problems

Mistaking “internal” for “safe”

A shared office network, VPN segment, or staging subnet is not the same as a hardened boundary. The vendor specifically warns about exposure on shared networks, not only the public internet.

Patching without secret rotation

This is the classic mistake. The Marimo RCE vulnerability may have been used to access local environment files or tokens already. A package upgrade closes the door. It does not erase what walked out through it.

Ignoring edit mode risk

Many teams think of notebook products as passive tooling. But the release notes and advisory make clear that editable notebook deployments are the key danger zone here. That distinction matters for triage.

Quick Comparison

Scenario	Risk Level	Why
Public Marimo notebook in edit mode	Very High	Reachable target plus direct shell path
Shared network exposure with weak segmentation	High	Internal attackers or compromised endpoints can pivot
App-only deployment behind strong access controls	Lower	Reduced attack surface, but still verify version and routes
Patched to 0.23.0 with secrets rotated	Much Lower	Vulnerability closed and post-compromise risk reduced

Field Notes for Security Teams

When a notebook platform gets hit by a pre-auth RCE, the first instinct is to think about code execution. Fair enough.

But the operational problem usually becomes credential exposure. That is where the pain starts. A shell on a data tool often means a short walk to your cloud account.

We have seen this pattern in incident response again and again. Attackers do not need to stay noisy.

They grab what is easy, use what works, and leave behind a patch of confusion. A few environment variables here, an SSH key there, maybe a service token nobody remembered was still active.

So the right question is not only “Did we patch Marimo?” It is “What did this host know, and did we change those secrets too?” That question saves far more pain than any status update ever will.

Act Now

• Patch Marimo 0.23.0 immediately

• Search for any exposed edit-mode notebooks

• Block public access until patching is complete

• Rotate secrets on hosts that were reachable

• Review logs for /terminal/WS activity

• Rebuild suspicious instances from clean images
  
  

Security Checklist

1. Upgrade to 0.23.0 on every Marimo host.

2. Remove public or shared-network exposure for edit-mode notebooks.

3. Rotate secrets and review logs if the host might have been reachable while vulnerable.

Trusted source: GitHub Security Advisory for GHSA-2679-6mx9-h9xc and the Marimo 0.23.0 release notes.

Research firm quote: Sysdig observed “credential theft in a matter of minutes.”

The hard truth is simple. The Marimo RCE vulnerability is the kind of bug that turns a developer convenience tool into an attacker foothold with very little effort. Patch it. Contain it. Then clean up the secrets that were close enough to get burned.

Author: Editorial Team
Published: April 13, 2026
Last Updated: April 13, 2026