CVE-2026-67618: PEP-723 config injection steals API

CISO Take

marimo, a Python notebook tool with built-in AI features, fails to sanitize inline PEP-723 script metadata before merging it into session configuration, letting a malicious notebook author embed a custom base_url that takes precedence over the operator's own settings. When the operator simply opens the crafted notebook and later makes any AI request in that session, marimo routes the call to the attacker's endpoint while still attaching the operator's OPENAI_API_KEY for authentication — handing over the credential with no cell execution required. This sits at medium severity (CVSS 6.5, EPSS 0.2%, no CISA KEV listing, no public exploit or Nuclei template, SSVC = TRACK), so it is not an active-exploitation emergency, but the near-zero interaction bar — just opening a notebook someone shared — makes it a realistic vector for any team that exchanges marimo notebooks with external collaborators. Upgrade to marimo 0.23.15+ now, treat externally-sourced notebooks as untrusted until reviewed, and rotate any OPENAI_API_KEY that may have touched a shared/unreviewed notebook.

Sources: NVD GitHub Advisory EPSS CISA SSVC ATLAS vulncheck.com

What is the risk?

Exploitability is high in relative terms for a UI:R vulnerability: attack complexity is low, no privileges are required, and the only user action needed is opening a notebook file — something data science and AI engineering teams do routinely with shared or downloaded notebooks. Impact is narrow but sharp: confidentiality is fully compromised (C:H) while integrity and availability are untouched, because the flaw leaks a single high-value secret (the operator's LLM API key) rather than granting code execution or data tampering. Exposure is elevated in AI-forward organizations where marimo is used for prototyping, notebook sharing is common practice, and API keys are frequently long-lived environment variables rather than short-scoped credentials — meaning a single leaked key can translate into ongoing unauthorized API usage or billing fraud until rotated. The absence of KEV listing, public exploit code, or a scanner template, combined with an EPSS score near zero, indicates this is not currently being mass-exploited, but the low bar to weaponize (crafting a notebook is trivial) means opportunistic abuse via social engineering (e.g., sharing 'useful' notebooks on GitHub or Slack) is plausible.

How does the attack unfold?

Malicious notebook delivery

Attacker crafts a marimo notebook embedding a malicious base_url in PEP-723 inline script metadata and distributes it as a legitimate-looking AI utility or tutorial.

AML.T0011.000

Config injection on open

Victim opens the notebook in marimo; insufficient sanitization in sanitize_pyproject_dict merges the attacker's base_url into session config with higher precedence than the operator's own settings.

AML.T0010.001

Triggered credential resolution

Operator makes a routine AI request within the session; marimo resolves the attacker-controlled base_url but falls back to the operator's real OPENAI_API_KEY environment variable for authentication.

AML.T0055

Key exfiltration

The operator's API key is transmitted to the attacker-controlled endpoint, giving the attacker unauthorized access to the victim's AI provider account.

AML.T0025

Malicious notebook delivery

Attacker crafts a marimo notebook embedding a malicious base_url in PEP-723 inline script metadata and distributes it as a legitimate-looking AI utility or tutorial.

AML.T0011.000

Config injection on open

Victim opens the notebook in marimo; insufficient sanitization in sanitize_pyproject_dict merges the attacker's base_url into session config with higher precedence than the operator's own settings.

AML.T0010.001

Triggered credential resolution

Operator makes a routine AI request within the session; marimo resolves the attacker-controlled base_url but falls back to the operator's real OPENAI_API_KEY environment variable for authentication.

AML.T0055

Key exfiltration

The operator's API key is transmitted to the attacker-controlled endpoint, giving the attacker unauthorized access to the victim's AI provider account.

AML.T0025

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 10% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Unchanged

C High

I None

A None

What should I do?

1 step

Upgrade marimo to 0.23.15 or later, which fixes the insufficient sanitization in sanitize_pyproject_dict per commit 1a21bd7 and PR #10281. Until upgraded, treat any marimo notebook received from outside your organization (or from unreviewed internal sources) as untrusted — do not open it in an environment where a real OPENAI_API_KEY (or other AI provider key) is configured until its PEP-723 metadata has been reviewed for unexpected base_url or config overrides. Rotate any API key that may have been active in a marimo session where an untrusted notebook was opened, and move toward per-project or per-user scoped keys with spend limits rather than shared organization-wide keys so a single leak has bounded impact. For detection, monitor egress logs and API provider dashboards for API calls or key usage against non-standard/unexpected endpoints, and consider network egress controls that restrict AI API traffic to known provider domains only.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage Supply Chain Social Engineering Framework API AML.T0010.001 - AI Software AML.T0011.000 - Unsafe AI Artifacts AML.T0025 - Exfiltration via Cyber Means AML.T0055 - Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

GOVERN-6.1 - Policies and procedures addressing AI risks from third-party entities

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-67618?

marimo, a Python notebook tool with built-in AI features, fails to sanitize inline PEP-723 script metadata before merging it into session configuration, letting a malicious notebook author embed a custom base_url that takes precedence over the operator's own settings. When the operator simply opens the crafted notebook and later makes any AI request in that session, marimo routes the call to the attacker's endpoint while still attaching the operator's OPENAI_API_KEY for authentication — handing over the credential with no cell execution required. This sits at medium severity (CVSS 6.5, EPSS 0.2%, no CISA KEV listing, no public exploit or Nuclei template, SSVC = TRACK), so it is not an active-exploitation emergency, but the near-zero interaction bar — just opening a notebook someone shared — makes it a realistic vector for any team that exchanges marimo notebooks with external collaborators. Upgrade to marimo 0.23.15+ now, treat externally-sourced notebooks as untrusted until reviewed, and rotate any OPENAI_API_KEY that may have touched a shared/unreviewed notebook.

Is CVE-2026-67618 actively exploited?

No confirmed active exploitation of CVE-2026-67618 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-67618?

Upgrade marimo to 0.23.15 or later, which fixes the insufficient sanitization in sanitize_pyproject_dict per commit 1a21bd7 and PR #10281. Until upgraded, treat any marimo notebook received from outside your organization (or from unreviewed internal sources) as untrusted — do not open it in an environment where a real OPENAI_API_KEY (or other AI provider key) is configured until its PEP-723 metadata has been reviewed for unexpected base_url or config overrides. Rotate any API key that may have been active in a marimo session where an untrusted notebook was opened, and move toward per-project or per-user scoped keys with spend limits rather than shared organization-wide keys so a single leak has bounded impact. For detection, monitor egress logs and API provider dashboards for API calls or key usage against non-standard/unexpected endpoints, and consider network egress controls that restrict AI API traffic to known provider domains only.

What systems are affected by CVE-2026-67618?

This vulnerability affects the following AI/ML architecture patterns: AI-assisted notebook environments, LLM API client configurations, collaborative notebook sharing workflows.

What is the CVSS score for CVE-2026-67618?

CVE-2026-67618 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.20%.

What is the AI security impact?

Affected AI Architectures

AI-assisted notebook environmentsLLM API client configurationscollaborative notebook sharing workflows

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0011.000 Unsafe AI Artifacts

AML.T0025 Exfiltration via Cyber Means

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: GOVERN-6.1

OWASP LLM Top 10: LLM02, LLM05

What are the technical details?

Original Advisory

marimo before 0.23.15 contains a configuration injection vulnerability that allows notebook authors to exfiltrate operator API keys by embedding a malicious base_url in PEP-723 inline script metadata, which is merged into session configuration with higher precedence than the operator's own settings due to insufficient sanitization in sanitize_pyproject_dict. When an operator opens the crafted notebook and makes an AI request, marimo resolves the attacker-controlled base_url from the notebook config while falling back to the operator's OPENAI_API_KEY environment variable for authentication, transmitting the API key to the attacker-controlled endpoint without requiring any cell execution.

Exploitation Scenario

An attacker crafts a marimo notebook — perhaps framed as a useful AI utility, demo, or tutorial — and embeds a malicious base_url pointing to an attacker-controlled server that mimics the OpenAI API surface, hidden inside the notebook's PEP-723 inline script metadata. The attacker distributes this notebook via GitHub, a Slack channel, a forum, or a notebook-sharing platform. A CISO's data scientist or AI engineer downloads the notebook and opens it in marimo — no cell execution is needed for the malicious config to take effect. Later, when that operator makes any ordinary AI request within the session (e.g., using marimo's built-in AI chat or code-assist feature), marimo resolves the attacker-controlled base_url from the notebook's embedded config, but still falls back to the operator's real OPENAI_API_KEY from their environment for authentication — silently transmitting that key to the attacker's endpoint, where it can be harvested and reused to make unauthorized calls against the victim's paid API account.

Weaknesses (CWE)

CWE-345 Insufficient Verification of Data Authenticity Primary CWE-345 Insufficient Verification of Data Authenticity

CWE-345 — Insufficient Verification of Data Authenticity: The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

Source: MITRE CWE corpus.