CVE-2026-66881

This vulnerability is not a simple missing validation check — it is a trust boundary bypass created by two enforcement paths that apply inconsistent security policies to the same data type. When a notebook is imported, the import path (`file_entry_metadata_to_attrs/1`) does not stamp URL-type file entries with quarantine flags. When the same entry would be added through the UI, `validate_file_entry_name/2` would apply stricter containment rules. The cache resolver (`file_entry_cache_file/2`) then resolves these entries at access time without any provenance check — it trusts that upstream validation already happened. The practical impact: a notebook imported from an untrusted source can contain URL-type file entries that write to disk without quarantine, even though equivalent entries created through the UI would be blocked or flagged. If your session's trust context changes later — role downgrade, tenant switch — those previously-imported entries remain executable without re-validation because the cache resolver performs no containment check at access time. For immediate mitigation, audit any Livebook instances that have imported notebooks from external sources since version 0.11.0. Check file_entry metadata in imported notebooks for URL-type entries that may have bypassed quarantine. The long-term fix requires either (1) applying quarantine stamps to imported URL entries at import time, or (2) consolidating all file entry creation through a single enforcement point that performs containment checks regardless of origin. The second approach is architecturally cleaner: treat the cache resolver as the definitive security gate rather than relying on disconnected validation at import and UI entry points. Adding provenance metadata to file entries would also enable runtime policy evaluation when session trust context changes, closing the temporal gap that validation alone leaves open.

Reviewed through automated stages and approved by a human before publication.