This CVE exposes a security control that exists at the UI layer but not at the API layer — a classic architectural trap in plugin-based systems. The lock-rule feature in JupyterLab enforces plugin restrictions through the UI, but direct API calls to the plugin management endpoints bypass those restrictions entirely. This isn't a bug in the enforcement logic; it's a missing enforcement layer where one was never implemented.
Two specific bypasses exist: the 'lock all' mechanism fails when extensions contain child plugins, and individual lock rules are ignored when called through the API rather than the UI. The CVSS 6.1 score reflects a narrow gap — you need to know the endpoint exists and call it directly — but that narrowness is itself informative. It suggests someone built the feature for the UI, treated the API as internal, and never wrote access control logic for it.
For defenders: check your deployment context. If you're running JupyterLab in JupyterHub with multi-user isolation, this bypass undermines any hardening controls those locked plugins provide — data governance, export restrictions, sanctioned extension sets. The severity isn't medium in isolation; it's medium conditional on whether your organization treats plugin locks as a security boundary or a convenience feature. Assume the former and audit accordingly.
For prioritization: the fix in 4.6.2 and 4.5.10 likely added conditional checks to this specific endpoint. That means other /lab/api/* administrative endpoints probably have the same gap. The pattern of 'works through UI, bypassed via API' is well-documented in plugin architecture vulnerabilities — this is the third or fourth instance in recent years across different platforms. Treat the fix as a symptom patch, not a cure.