CVE-2026-66881: path traversal — HIGH

CISO Take

Livebook fails to validate file paths when importing a .livemd notebook, letting an attacker embed a URL-type file entry whose name contains directory traversal sequences that Livebook's own path-resolution logic collapses without checking containment. If a victim opens and interacts with the malicious notebook, Livebook fetches attacker-controlled content and writes it to an attacker-chosen path on disk — no authentication or privileges needed on the target instance, only that one user action (CVSS 8.1, AC:L). There's no evidence of active exploitation (not in CISA KEV, no public PoC or Nuclei template, EPSS 0.38%, CISA SSVC rated TRACK_STAR), so this is not an emergency-patch scenario, but the attack requires nothing more than social engineering a data scientist into opening a shared notebook, and notebook stamping quarantine doesn't cover URL-type entries — meaning no warning is shown. Upgrade to Livebook 0.18.7 or 0.19.9 immediately, and until patched, treat inbound .livemd files from outside your team as untrusted content, review file_entries metadata before opening, and run Livebook with restricted filesystem permissions so a write-anywhere primitive can't reach cron jobs, SSH keys, or startup scripts.

Sources: NVD GitHub Advisory EPSS ATLAS cna.erlef.org

What is the risk?

High-severity, low-complexity vulnerability (CVSS 8.1) with no privileges required, but constrained by mandatory user interaction — an attacker cannot exploit this remotely without a victim opening a crafted notebook. Exploitation likelihood signals are currently low (EPSS 0.38%, top 69th percentile only, no KEV listing, no public exploit or scanner template, SSVC TRACK_STAR), so this is not being mass-exploited today. The real risk is targeted: a spearphished notebook sent to an ML engineer or data scientist is a low-friction social engineering vector, and the missing containment check plus the file-write primitive (arbitrary path, attacker-controlled content) gives a capable attacker a path to code execution by overwriting startup scripts, cron entries, or credential files.

How does the attack unfold?

Initial Access

Attacker crafts a .livemd notebook with a URL-type file_entries metadata block using an unvalidated, path-traversal-laden name and distributes it to a target via email, chat, or a shared repository.

AML.T0011

User Execution

Victim opens the notebook in their own authenticated Livebook session and interacts with the entry, triggering Livebook to fetch the attacker's URL content.

AML.T0011.000

Exploitation

Livebook resolves the unvalidated name beneath its temp directory without containment checks, collapsing traversal segments, and writes the fetched content to the attacker-chosen path outside the intended sandbox.

Impact

The attacker-controlled file lands wherever the Livebook process can write — e.g., overwriting SSH keys, cron jobs, or startup scripts — enabling persistence or follow-on code execution on the victim's system.

Initial Access

Attacker crafts a .livemd notebook with a URL-type file_entries metadata block using an unvalidated, path-traversal-laden name and distributes it to a target via email, chat, or a shared repository.

AML.T0011

User Execution

Victim opens the notebook in their own authenticated Livebook session and interacts with the entry, triggering Livebook to fetch the attacker's URL content.

AML.T0011.000

Exploitation

Livebook resolves the unvalidated name beneath its temp directory without containment checks, collapsing traversal segments, and writes the fetched content to the attacker-chosen path outside the intended sandbox.

Impact

The attacker-controlled file lands wherever the Livebook process can write — e.g., overwriting SSH keys, cron jobs, or startup scripts — enabling persistence or follow-on code execution on the victim's system.

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Unchanged

C None

I High

A High

What should I do?

1 step

Patch to Livebook 0.18.7 (for the 0.11.0–0.18.x line) or 0.19.9 (for 0.19.x) immediately — both branches fix validate_file_entry_name enforcement on import and add containment checks in file_entry_cache_file and to_attachment_file_entry. Until patched: do not open .livemd files from untrusted or unverified sources, inspect file_entries metadata manually for suspicious names (path separators, .. sequences, absolute paths) before importing, and run Livebook inside a container or restricted user account with minimal filesystem write access outside its designated temp/workspace directory. For detection, monitor for Livebook process file writes outside its expected temp directory and flag notebooks containing URL-type file entries with non-alphanumeric names.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

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

How is it classified?

Code Execution Social Engineering Supply Chain Framework AML.T0011 - User Execution AML.T0011.000 - Unsafe AI Artifacts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - Third-party and customer requirements

NIST AI RMF

MANAGE 4.1 - Post-deployment monitoring and incident response for third-party AI resources

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-66881?

Livebook fails to validate file paths when importing a .livemd notebook, letting an attacker embed a URL-type file entry whose name contains directory traversal sequences that Livebook's own path-resolution logic collapses without checking containment. If a victim opens and interacts with the malicious notebook, Livebook fetches attacker-controlled content and writes it to an attacker-chosen path on disk — no authentication or privileges needed on the target instance, only that one user action (CVSS 8.1, AC:L). There's no evidence of active exploitation (not in CISA KEV, no public PoC or Nuclei template, EPSS 0.38%, CISA SSVC rated TRACK_STAR), so this is not an emergency-patch scenario, but the attack requires nothing more than social engineering a data scientist into opening a shared notebook, and notebook stamping quarantine doesn't cover URL-type entries — meaning no warning is shown. Upgrade to Livebook 0.18.7 or 0.19.9 immediately, and until patched, treat inbound .livemd files from outside your team as untrusted content, review file_entries metadata before opening, and run Livebook with restricted filesystem permissions so a write-anywhere primitive can't reach cron jobs, SSH keys, or startup scripts.

Is CVE-2026-66881 actively exploited?

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

How to fix CVE-2026-66881?

Patch to Livebook 0.18.7 (for the 0.11.0–0.18.x line) or 0.19.9 (for 0.19.x) immediately — both branches fix validate_file_entry_name enforcement on import and add containment checks in file_entry_cache_file and to_attachment_file_entry. Until patched: do not open .livemd files from untrusted or unverified sources, inspect file_entries metadata manually for suspicious names (path separators, `..` sequences, absolute paths) before importing, and run Livebook inside a container or restricted user account with minimal filesystem write access outside its designated temp/workspace directory. For detection, monitor for Livebook process file writes outside its expected temp directory and flag notebooks containing URL-type file entries with non-alphanumeric names.

What systems are affected by CVE-2026-66881?

This vulnerability affects the following AI/ML architecture patterns: Notebook-based ML/data science development environments, Collaborative AI experimentation and research workflows, Interactive AI/ML tooling and prototyping pipelines.

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

CVE-2026-66881 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.42%.

What is the AI security impact?

Affected AI Architectures

Notebook-based ML/data science development environmentsCollaborative AI experimentation and research workflowsInteractive AI/ML tooling and prototyping pipelines

MITRE ATLAS Techniques

AML.T0011 User Execution

AML.T0011.000 Unsafe AI Artifacts

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

Relative Path Traversal vulnerability in livebook-dev livebook allows an attacker-authored notebook to write a file with attacker-controlled content to an arbitrary path. A .livemd notebook can declare file_entries metadata, each entry carrying a name. Every path that creates a file entry through the user interface validates that name with Livebook.Notebook.validate_file_entry_name/2, which requires a flat filename of alphanumerics, dashes, underscores and dots, ending in an extension. The import path does not: Livebook.LiveMarkdown.Import.file_entry_metadata_to_attrs/1 in lib/livebook/live_markdown/import.ex takes the name verbatim from the notebook source. For a URL-type file entry, Livebook.Session.file_entry_cache_file/2 in lib/livebook/session.ex resolves that name beneath the session's temporary directory without checking that the result stays inside it, and Livebook.FileSystem.Utils.resolve_unix_like_path/2 collapses parent-directory segments while clamping only at the filesystem root. When the entry's content is requested and no cached copy exists, Livebook fetches the entry's URL and writes the response body to the resolved path, creating parent directories as needed. The attacker therefore controls both the destination and the contents of the written file, which may land anywhere the Livebook process can write. The same missing containment check is present in Livebook.Session.to_attachment_file_entry/2. A victim who opens an attacker-supplied notebook and causes the entry to be fetched triggers the write within their own authenticated session; the attacker needs no account on the target instance. URL-type entries are also not placed under notebook stamping quarantine on import, so no warning is shown. This issue affects livebook: from 0.11.0 before 0.18.7 and from 0.19.0 before 0.19.9.

Exploitation Scenario

An attacker crafts a .livemd notebook containing a URL-type file_entries metadata block whose name field is a path traversal payload (e.g., `../../../../home/researcher/.ssh/authorized_keys`) instead of a validated flat filename, then shares it via email, a research Slack channel, or a public notebook-sharing repo as a legitimate-looking data analysis notebook. A data scientist opens the notebook in Livebook and interacts with the cell that triggers the file entry fetch (viewing or running it); Livebook resolves the traversal path beneath its temp directory without containment checks, fetches the attacker's URL, and writes the attacker-controlled response body to the target path — for example, overwriting the victim's SSH authorized_keys or a cron script — giving the attacker persistence or remote access without ever needing credentials on the victim's system.

Weaknesses (CWE)

CWE-23 Relative Path Traversal CWE-23 Relative Path Traversal

CWE-23 — Relative Path Traversal: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes: realpath() in C getCanonicalPath() in Java GetFullPath() in ASP.NET realpath() or abs_path() in Perl realpath() in PHP

Source: MITRE CWE corpus.