A security flaw in Marimo's Python notebook software allowed attackers to execute arbitrary Model Context Protocol (MCP) commands before any cell code ran. The vulnerability, tracked as CVE-2026-75149, affected versions prior to 0.23.15 and carried CVSS scores of 8.8 (v3.1) and 8.7 (v4.0).
This wasn't just a theoretical exploit. Opening a malicious notebook in edit mode triggered the attacker's commands immediately, no further user interaction was needed.
What Happened
Marimo notebooks store metadata in PEP 723 format within the notebook file itself. The vulnerability allowed attackers to inject malicious MCP commands into this metadata. When a user opened the notebook in edit mode, Marimo processed the metadata before executing any visible cell code, triggering the attacker's commands.
The attack vector involved distributing a notebook file via email, a repository, or any channel where users might open notebooks. Simply opening the file was enough to activate the exploit.
Timeline
The vulnerability existed in all Marimo versions prior to 0.23.15. VulnCheck's CNA record provided details on the flaw's scope and severity. Marimo released version 0.23.15 with a patch that changed how the software handles notebook metadata, treating it as attacker-controlled data instead of trusted configuration.
Which Controls Failed
Input Validation at the Metadata Layer
Marimo processed notebook metadata without treating it as untrusted input. This violates a core principle: any data crossing a trust boundary requires validation. The notebook file came from outside the application's control, making its contents, including metadata, untrusted by definition.
Separation of Configuration and Execution Contexts
The software executed MCP commands during the file-open operation, before the user saw any code or had a chance to review what would run. This collapsed two distinct security contexts: file parsing (which should be read-only) and command execution (which requires explicit user authorization).
Defense in Depth for Code Execution
A single control failure, the metadata parsing, led directly to arbitrary command execution. No secondary control caught the malicious activity. Your defense architecture should assume primary controls will fail and layer additional checks.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.2.4 mandates identifying and addressing common coding vulnerabilities during development. For applications that process external files, this means treating all file contents, including metadata, headers, and configuration sections, as potentially malicious input.
OWASP ASVS v4.0.3 Section 5.1.3 requires validating all input from untrusted sources. Notebook metadata qualifies as untrusted input because users can modify it outside your application's control. Validation must happen before you parse or act on the data.
ISO/IEC 27001:2022 Control 8.25 (secure coding) requires applying security principles during development, including least privilege and fail-safe defaults. Executing commands during file open violates least privilege, the operation should be read-only until the user explicitly chooses to run code.
NIST 800-53 Rev 5 Control SI-10 (information input validation) states you must check the validity of information inputs. This applies to all data entering your system, not just user-facing form fields. File metadata counts as an information input.
Lessons and Action Items
Treat All File Contents as Hostile
If your application processes files from external sources, audit every parsing operation. Configuration files, metadata sections, embedded scripts, and format-specific headers all require validation. Don't assume that "configuration" data is safe because it's not user-facing code.
Action: Map every file format your applications consume. For each format, document which sections contain executable or configuration data. Add input validation at the parsing layer before you act on any values.
Separate Parse Operations from Execution
File opening should be a read-only operation. Command execution, script running, or any state-changing action should require a separate, explicit user action. This gives users a chance to inspect what they're about to run.
Action: Review your application's file-handling code. Identify any operations that execute during file open or parse. Move those operations to explicit user-triggered actions with clear warnings about what will execute.
Implement CVE Tracking for Development Tools
Your security team probably tracks CVEs for production infrastructure, but development tools like notebooks, IDEs, and build systems also process untrusted input. A vulnerability in a developer's notebook environment can compromise source code, credentials, or development infrastructure.
Action: Add your development tools to your vulnerability management program. Subscribe to security advisories for notebook platforms, IDE plugins, and build tools. Treat high-CVSS vulnerabilities in dev tools with the same urgency as production systems.
Patch Development Environments Systematically
Developers often run outdated versions of tools because updates might break workflows or require reconfiguration. This creates a persistent attack surface.
Action: Establish a patching schedule for development tools. For high-severity vulnerabilities (CVSS 8.0+), require updates within your standard critical patch window, typically 15 days. Test updates in a staging environment first, but don't let testing delays extend beyond your patch deadline.
Audit Third-Party Integrations in AI Tools
The Marimo flaw involved MCP commands, a protocol for AI model interactions. As you integrate AI capabilities into development and production environments, each integration point becomes a potential attack vector. The Model Context Protocol, language model APIs, and AI service integrations all require security review.
Action: Inventory all AI and ML integrations in your environment. For each integration, document what commands or operations it can execute, what data it can access, and what authentication controls protect it. Apply the same security requirements you'd apply to any remote code execution capability.
The Marimo patch demonstrates the correct approach: treat notebook metadata as attacker-controlled. Apply this principle to every data source your applications consume. If a user can modify it, an attacker can modify it. Validate accordingly.
