The Marimo vulnerability tracked as CVE-2026-75149 is particularly interesting because it turns a notebook file itself into an execution trigger. Marimo is a reactive Python notebook environment used for data science, analysis and increasingly AI-assisted workflows. In affected versions before 0.23.15, a specially crafted notebook can include an attacker-controlled Model Context Protocol, or MCP, server command inside its configuration metadata. When a victim opens that notebook in edit mode, Marimo can launch the specified MCP command as a local subprocess before the user executes a single notebook cell. The vulnerability has been classified as CWE-94, Improper Control of Generation of Code, with a CVSS v4 score of 8.7 and CVSS v3.1 score of 8.8. ([thehackernews.com](https://thehackernews.com/2026/08/marimo-notebook-flaw-could-run-mcp.html))

This is an important distinction from the traditional notebook security model. Developers are accustomed to treating notebook cells as executable content. If someone downloads an unfamiliar Jupyter or Marimo notebook, they may reasonably inspect the cells before pressing Run. CVE-2026-75149 breaks that expectation because the dangerous behaviour can occur simply by opening the notebook in edit mode. The malicious command lives in notebook configuration rather than an obvious executable cell, so the victim may believe they are only reviewing the file while the application is already launching an attacker-controlled subprocess.

The underlying security problem involves the way Marimo processed PEP 723 inline metadata. PEP 723 allows Python scripts to contain structured metadata describing configuration and dependencies. Marimo used that metadata to construct notebook session configuration. Before the fix, notebook-supplied configuration could include an `mcp` section containing commands for starting MCP servers. Because this metadata was not sufficiently treated as untrusted input, an attacker could embed a command of their choosing and rely on Marimo to launch it automatically when the notebook was opened. The application was therefore allowing a document to influence process creation before the user had made an explicit decision to execute its code.

MCP makes the vulnerability particularly relevant to modern AI development environments. Model Context Protocol is intended to allow AI assistants and applications to communicate with external tools and data sources through standardised interfaces. An MCP server may legitimately be launched as a local subprocess to provide tools such as database queries, filesystem access or developer utilities. That capability is extremely useful, but it also means MCP configuration can be equivalent to executable configuration. If an attacker controls the command used to start the MCP server, they are not merely changing an AI preference; they are effectively selecting which program the operating system should execute.

This is why security teams should increasingly treat MCP configuration with the same caution applied to shell scripts, CI/CD workflows, package build scripts and IDE task definitions. A configuration file may look declarative, but if any field can spawn a process, download software or execute a command, that field is executable content from a security perspective. Calling it “configuration” does not make it passive, despite software engineering’s persistent enthusiasm for hiding powerful execution features inside YAML, JSON and metadata.

The attack does require user interaction. The attacker must convince the victim to obtain and open a malicious Marimo notebook in edit mode. This is reflected in the CVSS vector, which specifies required user interaction. However, no authentication is required from the attacker, and once the victim opens the crafted notebook, no notebook cell needs to be executed. The subprocess executes with the privileges of the user running Marimo.

That user context is what determines the potential impact. On a developer workstation, the Marimo process may have access to source-code repositories, SSH keys, Git credentials, cloud credentials, API tokens, environment variables, local datasets and internal network services. Successful code execution could therefore allow an attacker to read or modify files, install persistence, steal secrets or use the developer machine as a foothold into internal infrastructure. The CVSS assessment reflects potential high impact to confidentiality, integrity and availability on the affected system.

The consequences can be substantially greater in AI and data-science environments because notebooks frequently execute close to valuable data. Researchers may work with proprietary datasets, model weights, database credentials, OpenAI or other API keys, cloud storage tokens and access to GPU infrastructure. A malicious notebook capable of launching an arbitrary subprocess can potentially reach anything available to the user account or notebook environment. The attacker therefore does not need to exploit the AI model itself. Compromising the tooling surrounding the model may provide far more useful access.

CI/CD or automated notebook-processing environments could also be attractive targets if they open or process notebooks in editable contexts. Build and analysis systems frequently carry stronger credentials than ordinary developer machines because they need to access code repositories, package registries, cloud environments or deployment systems. If untrusted notebooks can reach such an environment, code execution could expose credentials capable of affecting production systems. Organisations should therefore determine not only whether developers use Marimo locally but whether automated systems ingest notebooks from external or semi-trusted sources.

The vulnerability also demonstrates why “do not execute untrusted notebooks” is no longer precise enough advice. In this case, opening the notebook is effectively execution. Users need to understand that notebook formats can contain configuration, extensions, dependencies and tool definitions capable of causing behaviour outside visible code cells. Security boundaries should therefore be enforced by the notebook application itself rather than relying entirely on users noticing malicious content during visual inspection.

Marimo addressed the vulnerability in version 0.23.15, released on July 23, 2026. The fix takes a broader approach rather than attempting to identify one dangerous MCP command. Marimo’s hardening patch treats notebook metadata as attacker-controlled and filters configuration through an allowlist. Notebook-supplied sections including `ai`, `mcp`, `completion`, `secrets` and `server` are removed before being merged into trusted session configuration. That approach is stronger because it prevents notebooks from overriding categories of configuration that can influence external services, credentials or process execution.

This is an important secure-design lesson. Security-sensitive configuration should not be inherited automatically from documents received from another user. The application should explicitly distinguish between portable notebook content and trusted local configuration. A notebook may reasonably define dependencies or presentation settings, but allowing it to redefine MCP servers, AI endpoints, secrets or server behaviour crosses into areas where the file itself begins controlling the execution environment.

The `mcp` section is not the only security-sensitive configuration Marimo had to address. The same configuration boundary was involved in CVE-2026-67618, disclosed earlier in August. That vulnerability allowed a malicious notebook to provide an attacker-controlled AI `base_url`. When the user subsequently made an AI request, Marimo could send the user’s existing `OPENAI_API_KEY` environment variable to the attacker-controlled endpoint, again without requiring execution of a notebook cell. Both vulnerabilities were fixed by the same 0.23.15 configuration-hardening work.

The relationship between CVE-2026-75149 and CVE-2026-67618 is particularly instructive. One vulnerability turns untrusted notebook configuration into local command execution, while the other turns the same configuration mechanism into credential exfiltration. Together they demonstrate why configuration injection deserves the same attention as conventional code injection. If an attacker can change which process launches, which server receives requests or which secret is supplied to that server, they may achieve the same outcome as injecting code directly.

There is also an important difference from Marimo’s earlier CVE-2026-39987. That vulnerability, disclosed in April 2026, involved missing authentication on the `/terminal/ws` WebSocket endpoint and allowed unauthenticated remote attackers to obtain a full pseudo-terminal shell on exposed Marimo servers. CVE-2026-75149 instead relies on a malicious notebook being opened by the victim. The earlier issue attacked a remotely reachable server endpoint; the new flaw attacks trust placed in notebook content. Marimo fixed the earlier vulnerability in version 0.23.0, while CVE-2026-75149 requires version 0.23.15 or later.

That distinction matters when administrators assess exposure. A Marimo deployment updated only to 0.23.0 may no longer be vulnerable to the April pre-authentication terminal RCE but can still be affected by CVE-2026-75149 and CVE-2026-67618. Version checking therefore needs to use the fixed version for the specific vulnerability rather than assuming that one earlier security update resolves every later issue.

The current PyPI release was 0.24.0 as of August 25, 2026, while the vulnerability is fixed beginning with 0.23.15. Organisations should therefore upgrade to 0.23.15 or later, preferably the current supported stable release according to their compatibility requirements. Marimo’s security policy encourages users to stay on the latest stable release because security patches are provided there.

At the time of the current CVE record, CISA’s SSVC enrichment listed exploitation as “none,” meaning there was no confirmed evidence of active exploitation in the wild. That is important to state accurately. CVE-2026-75149 is a high-impact vulnerability with a clear attack path, but it has not been placed in the same operational category as Marimo’s earlier CVE-2026-39987, which was exploited rapidly and later added to CISA’s KEV catalog.

The absence of known exploitation should not be used as a reason to postpone remediation. The attack concept is straightforward: place malicious MCP configuration inside a notebook and persuade somebody to open it. Technical details are now public, the affected range is known, and the vulnerability does not require exploitation of memory corruption or complex race conditions. Once attackers begin embedding these techniques into malicious repositories, tutorials, AI examples or downloadable notebooks, social engineering may become the more difficult part of the attack.

Developers should therefore treat notebooks obtained from GitHub repositories, forums, AI-generated examples, email attachments and shared project directories as untrusted until provenance is established. The source repository itself may also be compromised. A notebook appearing inside a familiar open-source project should not automatically receive more trust than any other executable artefact, particularly if the repository has recently changed ownership or accepted an unfamiliar contribution.

Organisations can reduce risk by reviewing notebook metadata before opening untrusted files on vulnerable versions. If immediate upgrading is impossible, the safest temporary measure is simply not to open untrusted Marimo notebooks in edit mode. Security teams can also scan files for PEP 723 metadata containing unexpected MCP configuration, though this should be treated only as an interim measure because attackers can adapt representation and future attack paths may involve different configuration fields.

Process monitoring provides another useful defensive layer. Opening a notebook should not normally result in arbitrary shell utilities, PowerShell, curl, wget or unfamiliar executables starting unless the user has explicitly configured such tooling. Endpoint security products can monitor parent-child process relationships and alert when a Marimo or Python process unexpectedly launches command interpreters, download tools or binaries from temporary locations.

Outbound network restrictions can further limit impact. Developer and notebook environments often need broad Internet access for package installation, but production analysis systems and controlled notebook workers can use repository proxies and allowlists. A malicious subprocess that cannot connect to arbitrary Internet destinations has fewer options for downloading second-stage malware or exfiltrating stolen secrets.

Secrets management is equally important. Developers should avoid placing long-lived cloud credentials and API keys directly into environment variables available to every notebook process where alternatives such as scoped secret stores or short-lived credentials exist. This recommendation is reinforced by CVE-2026-67618, where Marimo’s configuration handling could cause an operator’s OpenAI API key to be sent to an attacker-controlled endpoint.

Notebook environments processing untrusted content should ideally run inside containers or disposable virtual environments with minimal privileges. A successful subprocess execution should encounter only the files and network resources required for the task. Mounting the developer’s entire home directory, SSH configuration and cloud credentials into a notebook container defeats much of the benefit of isolation.

Running notebooks as root should be avoided completely. The attacker-controlled command inherits the privileges of the Marimo process, so least privilege directly determines the impact of exploitation. A dedicated unprivileged account with no administrative rights and limited filesystem access can substantially reduce the blast radius.

Organisations should also consider separating everyday development credentials from production credentials. A developer reviewing a notebook should not simultaneously possess administrator-level cloud tokens, production database passwords and code-signing keys within the same session environment. This is good security architecture regardless of CVE-2026-75149, but vulnerabilities like this demonstrate why such separation matters in practice.

For enterprise environments, software inventories should include developer tooling such as notebook platforms. Vulnerability management often concentrates on servers and Internet-facing appliances while tools installed through Python packages on developer workstations escape central visibility. Marimo can be installed through Python package management and may exist inside virtual environments that ordinary endpoint software inventories do not detect easily. Security teams should therefore use dependency and environment scanning capable of identifying installed Python package versions.

The MCP dimension deserves broader attention as well. Organisations adopting MCP should maintain an inventory of approved MCP servers and commands. Developers should not be able to silently introduce arbitrary local MCP processes into sensitive environments through documents or repository configuration. MCP server definitions should ideally come from trusted central configuration, signed project policies or explicit user approval rather than being automatically honoured from downloaded content.

MCP servers themselves should run with minimal permissions. A tool server that needs to query one local database does not require unrestricted filesystem access or the ability to read SSH keys. The principle is similar to browser extension security: every connected tool expands what the host application can do and therefore expands what an attacker may be able to abuse.

This vulnerability also has implications for AI-generated code and notebooks. Users increasingly ask AI assistants to generate complete analysis notebooks and then open those files locally. If the generated notebook incorporates configuration copied from an untrusted external source, malicious metadata may be substantially less visible than malicious code inside a cell. AI-assisted development workflows therefore need provenance and sandboxing rather than assuming generated artefacts are safe because no human adversary directly emailed them.

The larger lesson is that AI tooling is increasing the number of places where configuration can cause execution. MCP servers, notebook metadata, IDE agents, package managers and workflow definitions all blur the traditional distinction between “code” and “configuration.” Security teams should focus less on the filename extension and more on capability: can this artefact cause a process to start, a network request to occur, a secret to be read or an external tool to run? If the answer is yes, it belongs inside the execution threat model.

For customers using Marimo, the practical response should therefore be layered: upgrade to version 0.23.15 or later, preferably the current supported stable version; avoid opening untrusted notebooks on vulnerable installations; inspect PEP 723 metadata where necessary; monitor Marimo and Python processes for unexpected child processes; restrict notebook privileges and outbound connectivity; remove unnecessary secrets from notebook environments; isolate untrusted notebooks inside disposable containers or VMs; and establish governance around which MCP servers developers are allowed to run.

Organisations should also review environments where potentially untrusted notebooks were opened while running versions below 0.23.15. Investigators should look for unexpected subprocess execution around notebook-open times, suspicious shell or PowerShell activity, unfamiliar downloads, new persistence mechanisms and anomalous access to source-code repositories or credentials. There is currently no confirmed widespread exploitation, so this does not require assuming every vulnerable workstation is compromised, but high-value development environments warrant reasonable retrospective review.

CVE-2026-75149 ultimately demonstrates why the security boundary around notebooks must begin before the first visible code cell executes. A notebook is no longer merely a document containing Python snippets. It can contain dependencies, AI settings, secrets configuration and MCP tool definitions capable of changing the execution environment itself.

The most important takeaway is therefore not simply that Marimo had an MCP vulnerability. It is that software increasingly treats metadata as instructions. When a downloaded notebook can tell the application which local process to launch, opening that notebook becomes a security-sensitive action. Marimo’s fix correctly moves toward treating notebook metadata as attacker-controlled and allowing only safe configuration to cross that boundary. Other AI and developer platforms should adopt the same principle before their own supposedly passive project files acquire similarly surprising execution capabilities.

Marimo has addressed a high-severity security flaw in its notebook software that allowed an attacker to execute an attacker-supplied Model Context Protocol (MCP) command in a specially crafted notebook, according to VulnCheck's CVE Numbering Authority (CNA) record. The CNA record says the command can run as a local subprocess when the notebook is opened in edit mode. The vulnerability, tracked

Source: Marimo Notebook Flaw Could Run MCP Commands Before Cells Execute in Edit Mode via The Hacker News — published 25 Aug 2026.