The vulnerability arises because the trust command link handlers for markdownviewer and notebooks rely on the current active widget when a user answers the trust prompt, instead of the widget that originally triggered the prompt. If a different document becomes active while the prompt remains open, showing the trusted state for this new document incorrectly. Consequently, any later actions in the mistakenly trusted document—such as executing code cells—occur without another prompt. Trusting a notebook also writes any unsaved edits to disk and persists the Jupyter server signature, potentially allowing malicious persistence and execution. This flaw can unintentionally grant a user, or an attacker who can influence the trusted prompt, the ability to run arbitrary code from an untrusted document, weakening confidentiality, integrity, and availability of the system.

Affected products include JupyterLab (versions 4.5.7 through 4.5.11 and 4.6.4), JupyterLite Core, and Jupyter Notebook releases that bundle JupyterLab. Any application embedding these components inherits the same behavior until the vulnerability is patched in version 4.5.11 or 4.6.4.

The CVSS score of 4.2 reflects a low severity evaluation, and no EPSS score is available. The flaw is not listed in the CISA KEV catalog, indicating it is not a widely exploited vulnerability at present. The likely attack vector is local or in‑situ user interaction, wherein a malicious document or colluding user can cause the prompt to trust an unintended notebook, thereby executing code without additional authorization. While the immediate impact is limited to the user currently interacting with JupyterLab, the inadvertent persistence of trusted state and potential code execution present a moderate risk if the environment is used for sensitive analysis.