Marimo Notebook Flaw Could Run MCP Commands Before Cells Execute in Edit Mode

# Marimo's MCP Injection Flaw Ran Attacker Commands Before You Opened a Single Cell

## The Threat

A crafted Marimo notebook could silently launch a malicious subprocess on a victim's machine the moment they opened it in edit mode — before any notebook cell ever ran. The flaw, CVE-2026-75149, sits in how Marimo handled Model Context Protocol (MCP) configuration embedded in notebook metadata. An attacker who controlled the notebook file could specify an arbitrary MCP server command through that metadata, and Marimo would faithfully execute it as a local subprocess during startup.

The insidious quality of this attack is its timing. Most users think of notebook execution risk in terms of cells — dangerous code in a cell you accidentally run. This flaw bypasses that mental model entirely. The malicious payload fires during the editor's initialization sequence, giving the victim no visible indication that anything has happened. By the time you're staring at your notebook interface, the attacker's command has already run.

The configuration injection vector extends to a closely related flaw, CVE-2026-67618 (CVSS 7.1, disclosed August 4, 2026), where an attacker-controlled ai.base_url in notebook metadata redirected any AI API request to an attacker-owned endpoint — stealing the operator's API key without a single cell execution required. Together, these two vulnerabilities reveal a systematic problem: Marimo was treating notebook metadata as trusted configuration rather than attacker-controlled input.

## Severity and Impact

| Field | CVE-2026-75149 | CVE-2026-67618 |

|---|---|---|

| CVE ID | CVE-2026-75149 | CVE-2026-67618 |

| CVSS v4 Score | 8.7 | — |

| CVSS v3.1 Score | 8.8 | 7.1 |

| CWE | Code Injection | — |

| Attack Vector | Local (crafted notebook file) | Local (crafted notebook file) |

| Attack Complexity | Low | Low |

| Authentication Required | None | None |

| User Interaction | Required (open notebook in edit mode) | Required (open notebook + make AI request) |

| Published | August 19, 2026 | August 4, 2026 |

CVE-2026-75149 was assigned by VulnCheck's CVE Numbering Authority. Credit for discovery goes to Gregory Tan (handle: Grg0rry), who notably also appears as a co-author on Marimo's PEP 723 hardening commit — a clean example of a researcher staying involved through the fix.

## Affected Products

Marimo notebook software:

Current safe release: 0.24.0 (released August 17, 2026 on PyPI) — users on this version are not affected by any of the three CVEs.

## Mitigations

Update immediately. The current PyPI release is 0.24.0, which incorporates all three fixes. Running any version below 0.23.15 leaves you exposed to both CVE-2026-75149 and CVE-2026-67618.

pip install --upgrade marimo

What the patch does. Marimo's PEP 723 hardening commit now treats all notebook-supplied configuration as attacker-controlled. The following metadata sections are stripped through an allowlist before the notebook environment initializes:

Verify your installed version before opening any notebook from an untrusted source:

python -m marimo --version

Operational controls while patching:

Marimo's security policy covers only the latest stable release. There are no backported patches — upgrade is the only supported path.

## References

---

## HackWire Analysis

Three separate CVEs against Marimo's configuration boundary in the span of a few months should be read as a signal, not a coincidence. CVE-2026-39987 gave attackers a raw PTY shell through an unauthenticated WebSocket. CVE-2026-67618 quietly redirected AI API calls to harvest keys. CVE-2026-75149 ran arbitrary subprocesses before the user could react. Each flaw shares the same root assumption: that data embedded in a notebook file could be trusted as configuration. That assumption was wrong each time.

This matters beyond Marimo. Notebooks are the currency of data science and AI development teams — they get shared on GitHub, emailed between collaborators, posted in Slack, and cloned from public repos. They look like documents. They behave like executables. The security community has known this about Jupyter for years; the same lesson is now being relearned with every new notebook runtime that enters the ecosystem.

The MCP angle deserves particular attention. As AI tooling proliferates, MCP is becoming the standard plumbing for connecting language models to local resources. Any runtime that auto-initializes MCP servers from file-embedded configuration — without treating that configuration as hostile — is building a pre-execution attack surface into every file it opens. Marimo's hardening patch (strip the MCP config block before initialization) is the right answer, but the industry has not internalized this pattern yet. Security teams should be asking that question of every AI-adjacent tool in their stack: what does this software do before the user runs anything?

For defenders, the practical message is simple: treat notebooks exactly like you treat executable files. Scan them before opening, enforce source controls, and keep runtimes patched. The "it's just a notebook" intuition is exactly what attackers are counting on.

— HackWire Editorial

## Related Coverage