On April 8, 2026, a critical vulnerability was disclosed in marimo, an open-source reactive Python notebook platform. Currently being tracked as GHSA-2679-6mx9-h9xc, it is a pre-authentication remote code execution (RCE) vulnerability in the terminal WebSocket endpoint that allows attackers to obtain a full interactive shell on any exposed marimo instance through a single WebSocket connection – no credentials required. At the time of this writing, a CVE number has yet to be assigned.

Within 9 hours and 41 minutes of the vulnerability advisory’s publication, the Sysdig Threat Research Team (TRT) observed the first exploitation attempt in the wild, and a complete credential theft operation was executed in under 3 minutes. No public proof-of-concept (PoC) code existed at the time. The attacker built a working exploit directly from the advisory description, connected to the unauthenticated terminal endpoint, and began manually exploring the compromised environment. This also recently happened with a Langflow flaw (CVE-2026-33017), where, with no public exploit, the vulnerability was exploited within 20 hours. This marimo vulnerability exploitation cuts that time in less than half.

What makes this case particularly notable is the target: Marimo is not a household name in enterprise software. With approximately 20,000 GitHub stars, it is a fraction of the size of platforms like Langflow (145,000+ stars) or n8n (75,000+ stars) that have historically attracted mass scanning campaigns. The speed of exploitation seen by the Sysdig TRT suggests that threat actors are monitoring advisory feeds broadly, not just for high-profile targets, and are capable of weaponizing vulnerabilities in niche software within hours of disclosure. It also implies that threat actors are using AI to analyze vulnerability advisory descriptions, build working exploits, and accelerate their operations.

Within hours of the advisory’s publication, the Sysdig TRT deployed honeypot nodes running vulnerable marimo instances across multiple cloud providers. The activity TRT captured, detailed below, provides a clear picture of how a single attacker moved from initial access to credential theft in a matter of minutes.

Timeline

The gap between advisory publication and first exploitation was 9 hours and 41 minutes. No public PoC code existed on GitHub or any major exploit repository at the time of the initial attack. The advisory itself contained enough detail for an attacker to construct a working exploit: the vulnerable endpoint path (/terminal/ws) and the fact that it lacked authentication, unlike the other WebSocket endpoints in the application.

About the vulnerability

Marimo is an open-source reactive Python notebook designed as a modern alternative to Jupyter. It stores notebooks as pure Python files, supports reactive execution, and can be deployed as interactive web applications. While smaller than mainstream notebook platforms, marimo has an active community and is used in data science and research workflows.

GHSA-2679-6mx9-h9xc (CVSS v4.0: 9.3, Critical) affects the /terminal/ws WebSocket endpoint in marimo versions 0.20.4 and earlier. The vulnerability is straightforward. This endpoint provides an interactive PTY (pseudo-terminal) shell but completely lacks authentication validation. Other WebSocket endpoints in the application, such as /ws, correctly call validate_auth() before accepting connections. The terminal endpoint skips this check entirely, accepting connections from any unauthenticated user and granting a full interactive shell running with the privileges of the marimo process.

The fix was released in version 0.23.0 via PR #9098: https://github.com/marimo-team/marimo/pull/9098.

Several characteristics made this vulnerability attractive despite marimo's relatively small user base:

• No authentication required. The exploit is a single WebSocket connection. No credentials, no tokens, no session management.
• Interactive shell access. Unlike many RCE vulnerabilities that require crafting payloads for each command, this provides a persistent interactive terminal. The attacker can type commands and see output in real time, just like SSH.
• Trivial exploitation. The advisory describes exactly which endpoint is affected and why. Any attacker who can open a WebSocket connection to /terminal/ws has a shell. There is no payload to craft, no injection to format, no encoding to get right. The attacker can walk right in.
• High-value environment. Notebook platforms are configured with database connections, API keys, cloud credentials, and access to datasets. Compromising one instance can provide lateral access to connected infrastructure.

What we observed

Over the first 12 hours following advisory publication, we recorded exploit activity from one source IP targeting our honeypot fleet. An additional 125 unique IPs conducted reconnaissance (port scanning, HTTP probing), but only one progressed to actual exploitation of the WebSocket terminal vulnerability.

Session 1: PoC validation (07:31 UTC)

The attacker connected to the /terminal/ws WebSocket endpoint on the honeypot GCP node in europe-west1-b and immediately ran a scripted validation sequence:

echo '---POC-START---'
id
echo '---POC-END---'

The marker strings (---POC-START--- and ---POC-END---) and the use of id as the test command indicate this is a structured PoC script, not manual typing. The attacker is confirming code execution before investing time in manual exploration. The session lasted 9 seconds before the attacker disconnected.

Session 2: Manual reconnaissance (07:33 UTC)

Two minutes later, the attacker reconnected and began manual exploration:

pwd         → /app/marimo
whoami      → marimo
ls          → marimo  logs  data  .env  docker-compose.yml  celerybeat-schedule

The attacker attempted to navigate the filesystem using cd ../, cd logs, and cd ~/.ssh, and ran ls after each attempt to check their position. They also tried ipaddr (likely meaning ip addr) to enumerate network interfaces. These reconnaissance processes appeared to be manual, not AI-driven, based on the timeline and steps taken.

Session 3: Credential theft (07:43 UTC)

After a 6-minute pause, the attacker reconnected for a focused credential harvesting session. They immediately listed the directory and then targeted the .env file:

ls          → marimo  logs  data  .env  docker-compose.yml  celerybeat-schedule
cat .env    → HOME=/app/marimo
               PATH=/usr/local/bin:/usr/bin:/bin
               HOSTNAME=prod-app-e29e
               AWS_DEFAULT_REGION=us-east-1
               AWS_ACCESS_KEY_ID=AKIA01FB...

The honeypot returned realistic fake credentials in the .env response, including AWS access keys and application secrets. In a real deployment, this is exactly the data an attacker would need to pivot from the compromised notebook instance to cloud accounts, databases, and third-party APIs.

The attacker then methodically attempted to read every file in the directory:

cat data
cat docker-compose.yml
cat celerybeat-schedule
cat marimo
cat logs

They also searched for SSH keys:

ls ~
ls ~/
ls ~/.ssh
cd ~/ssh
cd ~/.ssh

The session ended with the attacker running exit at 07:45 UTC. This is a complete credential theft operation executed in under 3 minutes.

Session 4: Return visit (08:57 UTC)

Over an hour later, the attacker returned and re-ran their PoC validation script (echo markers + id), then reconnected and re-read the .env file. They also ran history, likely checking whether other attackers had been active on the same instance. The session ended at 09:04 UTC.

Attacker profile

The exploitation patterns reveal a methodical operator, not an automated scanner:

• Scripted PoC first: The marker-delimited validation step suggests a workflow where the attacker runs a script to confirm the vulnerability, then switches to manual interaction.
• Focused objectives: The attacker went directly for .env credentials and SSH keys. They did not attempt to install persistence, deploy cryptominers, or download additional tools.
• Multiple sessions: The attacker connected four times over 90 minutes, with pauses between sessions. This is consistent with a human operator working through a list of targets, returning to confirm findings.

What this means for defenders

The 9-hour-41-minute window between advisory publication and first exploitation continues a trend that has been accelerating over the past several years. The Zero Day Clock project, which tracks data across 83,000+ CVEs, shows the median time-to-exploit has collapsed from 771 days in 2018 to just hours in recent years. By 2023, 44% of exploited vulnerabilities were weaponized within 24 hours of disclosure. The Sysdig TRT’s observation of GHSA-2679-6mx9-h9xc fits squarely in this trend.

What distinguishes this case is the target. Marimo is not Langflow, not Jenkins, and not GitLab. It has 20,000 GitHub stars, not 145,000. It does not currently appear in CISA's Known Exploited Vulnerabilities (KEV) catalog. It is not a common target for mass scanning campaigns. Yet, within 10 hours of a critical advisory being published, an attacker built a working exploit and was actively harvesting credentials from exposed instances much faster than vulnerable organizations could manually patch.

This has implications for how organizations assess their exposure:

• Niche or less popular software is not safer software. The assumption that attackers only target widely deployed platforms is wrong. Any internet-facing application with a critical advisory is a target, regardless of its popularity.
• Advisory detail enables exploitation. GHSA-2679-6mx9-h9xc required no reverse engineering to exploit. The advisory named the endpoint, described the missing authentication check, and identified the affected versions. This level of detail, while essential for defenders, is equally useful to attackers.
• No CVE ≠ no exploitation. At the time of this writing, no CVE number has been assigned to this vulnerability, but exploitation is already happening. Organizations that rely on CVE-based scanning or alerting would not have flagged this advisory at all.
• Interactive shells change the calculus. Most automated RCE exploitation involves a single command per request. A WebSocket terminal provides persistent, interactive access. This makes post-exploitation faster and more thorough because the attacker does not need to craft a new payload for each command.

Indicators of compromise

Source IPs

Note: The source IP may be a proxy or VPN endpoint rather than the operator's true origin.

Recommendations

• Update marimo to version 0.23.0 or later immediately. If upgrading is not possible, restrict network access to the /terminal/ws endpoint or disable the terminal feature entirely.
• Audit environment variables, .env files, and secrets on any marimo instance that has been publicly accessible. Rotate AWS credentials, API keys, database passwords, and SSH keys as a precaution.
• Restrict network access to marimo instances using firewall rules or a reverse proxy with authentication. Notebook platforms should not be directly exposed to the internet without an authentication layer.
• Monitor for WebSocket connections to /terminal/ws from unexpected sources. Legitimate use of the terminal feature should be limited to authenticated users on internal networks.
• Inventory notebook and data science tooling in your environment. Platforms like marimo, Jupyter, and other notebook tools are frequently deployed by research teams outside of standard security review processes and may be running with broad cloud credentials.

Conclusion

GHSA-2679-6mx9-h9xc demonstrates that the collapse of exploitation timelines is not limited to the most popular software. A critical vulnerability in a Python notebook with 20,000 GitHub stars was weaponized in under 10 hours, with no public PoC and no CVE number assigned, and a complete credential theft operation was executed in under 3 minutes. The attacker needed nothing more than the advisory text and a WebSocket client.

For defenders, the takeaway is that advisory monitoring must extend beyond CVE databases and high-profile projects. Any internet-facing application with a published critical vulnerability is a potential target within hours of disclosure, regardless of its install base.

Runtime detection, network segmentation, and rapid credential rotation remain the most effective controls when the patch window is measured in hours rather than days.