CVE-2026-66298

The vulnerability in CVE-2026-66298 is fundamentally an architectural issue, not just a missing isTrusted check. The session-level keyboard shortcut handler in this notebook application registers on the capture phase, meaning every keydown event arriving at the document is consumed before any downstream validation can inspect it. This design choice — made to ensure consistent shortcut behavior regardless of where the user is typing — creates a structural impossibility: you cannot add any validation logic after a capture-phase handler because the handler already ran. The actual attack surface is a cross-origin iframe (the sandboxed output rendering context) that forwards every keydown to the parent window without inspection. The missing isTrusted check at the forwarding boundary is the symptom, not the disease. The disease is that the capture-phase handler cannot distinguish between a keydown originating from the trusted editor context versus one tunneled through the untrusted iframe. What you should check and fix: First, verify whether the shortcut handler in session.js (or equivalent) uses addEventListener with a third argument of true (capture phase). If it does, the core fix is moving it to the bubble phase — but bubble phase alone doesn't solve the problem because a compromised iframe could still dispatch trusted events directly on the parent document. The robust fix requires provenance validation at execution time, not phase relocation alone. Specifically, the shortcut handler must assert two things before executing sensitive actions: (1) the event's composedPath() shows its initial target is within the active editor's DOM subtree, and (2) the composedPath() chain includes the iframe element that initiated the relay. This two-part check handles both the stale-focus case (wrong editor document) and the case where an attacker dispatches directly on the parent bypassing the relay entirely. Alternatively, if moving to bubble phase is not feasible, the session-level shortcuts should require a secondary confirmation tied to focus context — only events originating from the actual notebook editor should trigger sensitive actions. The WeakMap approach (tracking active document state) works but has a timing window between focus changes and handler invocation; the composedPath() check at execution time is tighter. The vulnerability existed from version 0.5.0 through 0.19.9. If you're on any version in that range, prioritize either the provenance check or bubble-phase relocation with the composedPath() validation as your immediate mitigation.

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