As reported by The Hacker News, Marimo has patched a high-severity code injection flaw (CVE-2026-75149) that allowed attacker-supplied Model Context Protocol (MCP) commands to execute as local subprocesses the moment a victim opened a crafted notebook in edit mode — before any cell ran. This is not an isolated bug. It is the third disclosed vulnerability in Marimo this year stemming from the same root cause: trusting notebook-supplied configuration metadata.

Security Impact: As reported by The Hacker News, Marimo has patched a high-severity code injection flaw (CVE-2026-75149) that allowed attacker-supplied Model Context Protocol (MCP) commands to execute as local subprocesses the moment a victim opened a crafted notebook in edit mode — before any cell ran.

Vulnerability Summary

IdentifierCVE-2026-75149
SeverityHigh — CVSS v4 8.7 / CVSS v3.1 8.8
TypeCode injection via notebook MCP configuration
AffectedMarimo < 0.23.15
Patched in0.23.15 (July 23, 2026); current release 0.24.0
ExploitationNo confirmed wild exploitation; PoC path described in CNA record
PrerequisitesUser interaction (open notebook in edit mode); no attacker auth
Related CVEsCVE-2026-67618 (AI base_url exfil, CVSS 7.1), CVE-2026-39987 (missing auth, ≤0.20.4)

Why This Pattern Matters More Than the Single CVE

The most important detail in this advisory is not the MCP command path itself — it is that Marimo's own hardening commit explicitly treats notebook metadata as attacker-controlled and strips five configuration sections (ai, mcp, completion, secrets, server) through an allowlist. That language tells us the previous architecture assumed notebook files were semi-trusted configuration carriers. They are not. Notebooks are arbitrary documents exchanged across teams, forks, and public repositories; their metadata is as hostile as any email attachment.

This is the same trust boundary confusion that plagued Jupyter notebooks for years before sandboxing and nbconvert hardening became standard. Marimo is now learning the same lesson, faster and with MCP in the mix — which makes the blast radius worse because MCP servers can invoke filesystem access, shell execution, and external API calls by design.

Who Is Most Exposed

  • Data science and ML teams who share .marimo notebooks internally or pull them from public repos and GitHub gists.
  • Research and academic environments where notebooks are routinely opened in edit mode by default, satisfying the user-interaction requirement trivially.
  • Organizations piloting MCP-integrated dev environments — the subprocess launch happens pre-cell-execution, so even security-conscious users who never run a cell are compromised.
  • CI/CD pipelines that render or lint Marimo notebooks if they load metadata without sanitization.

Detection Considerations

Defenders should instrument for the behavior, not just the CVE. Monitor for unexpected child processes spawned by the Marimo process, especially node, npx, python -m, or arbitrary binaries launched with arguments referencing URLs or stdio transport flags common to MCP server launches. On macOS and Linux, execve tracing via eBPF or Endpoint Detection and Response (EDR) process lineage alerts tied to the Marimo parent process will catch both this CVE and future metadata-injection variants.

Shield53 Recommendations

  • Upgrade immediately to Marimo 0.24.0 (or at minimum 0.23.15). Verify with marimo --version and check CI base images.
  • Treat all inbound notebooks as untrusted — open them in a container or VM, never on a developer workstation with production credentials, SSH keys, or MCP server configs present.
  • Audit existing MCP configurations in your environment and remove any server entries that auto-start from notebook metadata.
  • Apply allowlist enforcement at the orchestration layer: if your platform renders Marimo notebooks programmatically, strip the ai, mcp, completion, secrets, and server metadata sections before loading, mirroring the upstream patch.
  • Block notebook file types at email and collaboration gateways where feasible, or route them through a sandboxed inspection pipeline.
  • Hunt for prior compromise: review process execution logs for the last 90 days for Marimo-spawned subprocesses that do not correspond to expected cell activity.
  • Track CVE-2026-67618 and CVE-2026-39987 remediation as well — if you were running a vulnerable version for 75149, you were likely exposed to the base_url API-key exfiltration path too.

The takeaway for security leaders is architectural: MCP is expanding the attack surface of every tool that embeds it, and notebook platforms that accept rich configuration from document metadata are now prime targets. Expect more CVEs in this class across the AI tooling ecosystem through 2026. The fix is not just patching — it is enforcing a hard trust boundary between document content and runtime configuration everywhere notebooks are opened.