JupyterLab EUVD-2026-57796

Exploitation requires a valid authenticated session on the JupyterLab server (PR:L confirmed by CVSS vector). Beyond authentication, the attack only has material impact when an administrator has configured plugin lock rules - either via the 'lock all' mechanism or by locking child plugins of multi-plugin extensions (AT:P in CVSS 4.0 reflects this prerequisite). In deployments where no plugin locks are configured, there is nothing to bypass and the vulnerability is effectively inert. The bypass is scoped to enabling or disabling plugins within the attacker's own session; it does not grant access to other users' sessions, other system resources, or allow direct code injection. Exploitation is therefore most relevant to multi-user JupyterHub environments where administrators enforce per-user plugin restrictions to implement security boundaries such as data exfiltration controls.

The CVSS 4.0 score of 6.0 with vector AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:N reflects a medium-severity issue. The AT:P metric (attack requirements present) is significant: exploitation only has meaningful impact when an administrator has actively configured plugin lock rules - deployments without locks have no security boundary to bypass. PR:L confirms authentication is required. The high integrity impact (VI:H) is appropriate given that an attacker can directly subvert administrative security controls, not merely read data. No CISA KEV listing and no identified POC reduce operational urgency for most environments. However, organizations running multi-user JupyterHub deployments where locked plugins enforce data governance or exfiltration controls face elevated real-world risk, as the bypass directly nullifies those controls. For environments with no administrator-configured locks, the practical risk is negligible despite the network-accessible attack vector.

An authenticated user on a shared JupyterHub server, aware of the /lab/api/plugins endpoint, sends a direct HTTP POST request to enable a file-download plugin that the administrator locked to enforce a data retention policy. With the plugin re-enabled within their session, the user can download restricted datasets, bypassing the intended organizational control. No public proof-of-concept code has been identified, but the attack requires only a valid session token and knowledge of the target plugin identifier, both of which are readily obtainable within the application.