Jupyter nbconvert EUVD-2026-107551

Exploitation requires a victim to convert an attacker-supplied notebook using specifically the markdown, LaTeX, reStructuredText, or AsciiDoc exporter - NOT the default HTML exporter - and the notebook must contain cell output metadata whose 'filename' field embeds path traversal sequences (e.g., '../../'); this is the exact precondition for ExtractOutputPreprocessor joining the filename to output_files_dir without directory confinement. Limiting factors: the attack requires active user interaction (the victim must initiate conversion with a vulnerable exporter), only affects nbconvert 5.4.0 through 7.17.1, writes are bounded to filesystem locations writable by the victim's own user account, and merely re-running the notebook cell would overwrite the malicious metadata - but simply converting the supplied notebook does not, which is why delivery as a static notebook works.

The input provides only a CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, base 8.8). No EPSS probability, no SSVC decision data, and no KEV entry were supplied, and no public exploit is identified in the references (the only code is the vendor fix commit and its regression tests). The headline 8.8 is driven by all-High impact and subsequent-system metrics, but two signals pull real-world risk down: AT:P (attack requirement - a specific non-default exporter must be used) and UI:A (the victim must actively run a conversion), which together make this non-automatable and non-wormable. This is a user-interaction-gated arbitrary file write, not a remotely-triggerable server exploit, so it is best treated as a moderate, targeted/social-engineering risk rather than a mass-exploitation priority - elevated mainly by nbconvert's very wide deployment. One conflict to flag: the supplied vector uses PR:L, but the attacker needs no privileges on the victim system - they only supply a crafted notebook - so I independently assess PR:N; verify privilege assumptions before using the 8.8 for prioritization. Exploitation status: no public exploit identified at time of analysis.

An attacker publishes or emails a malicious Jupyter notebook (e.g., in a public repo or shared dataset) whose cell output metadata contains a filename with path traversal sequences such as '../../.bashrc'. A victim converts it with a vulnerable exporter (nbconvert --to markdown/latex/rst/asciidoc), causing attacker-controlled output bytes to be written outside output_files_dir to an arbitrary location the victim's user can write, such as a shell startup file, enabling later code execution. No public POC is identified; the vendor's regression test demonstrates the traversal conceptually but is defensive, and UI:A/AT:P means the victim must actively convert using a non-default exporter.