JupyterLab EUVD-2026-98809

Exploitation requires that the markdownviewer:trust or notebook:trust command-link flow be used - i.e. a document containing a command-linker Trust button - and that a second document become the current widget in the shell tracker during the brief interval between the user clicking the button and answering the Trust dialog. The user MUST actively choose 'Trust' (and confirm notebook trust), so social engineering or a realistic multi-document workflow is needed. Limiting factors: the race window is narrow (AC:H), success depends on controlling or predicting which widget becomes current at answer-time, and no elevated privileges are needed because the victim operates their own JupyterLab session (PR:N); only affected versions 4.5.7 up to the 4.5.11/4.6.4 fixes are exposed.

This is a genuine but low-urgency issue, and the signals are internally consistent rather than conflicting. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N, base 4.2 Medium) correctly reflects a CWE-367 time-of-check/time-of-use race: AC:H captures the narrow timing window (the victim must switch the current document while the Trust prompt is open), and UI:R captures the mandatory human action of clicking Trust. No EPSS score was supplied, there is no CISA KEV listing, and no public exploit is referenced, so exploitation status is 'no public exploit identified at time of analysis.' The impact is a trust-boundary/integrity bypass (one document trusted instead of the one whose button was clicked), which maps better to the I:L rating than to the 'Information Disclosure' tag applied in the input - the real consequence is unprompted execution of command-links and persisting a server trust signature, not data leakage. Net: a legitimate security fix worth patching on normal cadence, not an emergency; the combination of high attack complexity, required user interaction, and no evidence of in-the-wild use places it well below actively-exploited priorities.

An attacker shares a crafted notebook or Markdown document containing a command-link Trust button. When a victim clicks Trust, the attacker (or an unlucky timing of the victim's own window switching) causes a different, attacker-controlled document to become the current widget before the victim confirms, so JupyterLab trusts that second document instead. Later command buttons in the wrongly-trusted document then execute without any prompt. No public exploit code is identified, and the race window plus required user interaction make reliable exploitation difficult.