Database/AI/ML frameworks & serving
nbconvert: notebook output metadata filename escapes output_files_dir, writing files anywhere the converter can reach
Impact
ExtractOutputPreprocessor joins the cell output metadata filename - which comes from the notebook file, not from the operator - to output_files_dir without confining the result to that directory. Converting an untrusted notebook with the markdown, LaTeX, reStructuredText or AsciiDoc exporter can therefore write attacker-chosen bytes to any path the converting user can write. This matters where nbconvert runs unattended on shared infrastructure: report pipelines, CI jobs and documentation builds that convert user-submitted notebooks can have files planted in a home directory, a job script path or a config location, which is a route to code execution the next time something reads what was written. Simply converting the notebook is enough; the malicious output metadata is only cleared if the cell is executed again. Affects 5.4.0 up to 7.17.2.
Who can reach it
Anyone who can get a notebook file in front of a conversion step - a repository contributor, a user uploading to a report service, or a job submitter in a shared cluster. No authentication to nbconvert itself; it needs a victim or an automated pipeline to run the conversion.
What to do
Upgrade nbconvert to 7.17.2 and redeploy any image or environment that pins it, then restart the pipelines or services that invoke it. No node drain or reboot. Until then, run conversions of untrusted notebooks under an unprivileged account in a disposable container rather than in CI workspaces or user home directories.
References
Related entries
- vLLM: forged shared-memory handles in multimodal kwargs reach pickle.loads on workersCVE-2026-115912 · vLLM (shared-memory multimodal feature cache)High
- vLLM: attacker-supplied X-Request-Id makes a prefill worker ZMQ-connect out, leaking NCCL id and KV cacheCVE-2026-116176 · vLLM P2pNcclConnector (decode address from X-Request-Id header)High
- OpenShift AI dashboard: incorrect network binding lets an in-cluster actor impersonate any user with an arbitrary tokenCVE-2026-16745 · Red Hat OpenShift AI odh-dashboard (network binding / token handling)High
- Langflow: incomplete filtering of Docker volume and device arguments exposes host files from a flowCVE-2026-17626 · IBM Langflow OSS (Docker-based MCP server argument filtering)High
- OpenShift AI training-operator: namespace edit/admin users escalate to host filesystem access via crafted training jobsCVE-2026-18982 · Red Hat OpenShift AI training-operator (ClusterRole aggregation + PodTemplateSpec passthrough)High
- vLLM (HF `auto_map`): Loads Hugging Face dynamic modules during model resolutionCVE-2026-22807 · vLLM (HF `auto_map`)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.