GPU VulnDB

Database/AI/ML frameworks & serving

JupyterLab: saved HTML cell output can run arbitrary JupyterLab commands on one user click

CVE-2026-42557AI/ML frameworks & servingcurated

Impact

The sanitizer allowlists data-commandlinker-command and data-commandlinker-args on buttons, and CommandLinker executes the named command for any click on document.body without checking that the element came from trusted JupyterLab UI. A notebook whose stored HTML output contains a deceptive button therefore triggers arbitrary JupyterLab commands - including code execution - the moment a user clicks it, with no cell ever being run. On a shared GPU cluster this turns a notebook file into a delivery mechanism: a shared, downloaded, or cloned notebook opened by another user runs code as that user, in that user's kernel, on whatever GPU node the kernel landed on, with their tokens and mounted dataset shares. Red Hat ships the affected code in OpenShift AI 3.4 workbench images, so multi-tenant notebook platforms inherit it.

Who can reach it

Anyone who can get a notebook file in front of a JupyterLab user - a shared project directory, a git repo, a dataset bundle, or a link to a hosted workbench. No authentication to the server is needed by the attacker, but the victim must open the notebook and click the planted button.

What to do

Upgrade JupyterLab to 4.5.7 and restart the notebook servers; on OpenShift AI apply RHSA-2026:43038 / RHSA-2026:60520 and roll the workbench images so running notebook pods pick up the fix. This is a userspace Python package - no node drain or reboot, but every running single-user server keeps the vulnerable frontend until it is restarted, so plan a workbench restart cycle rather than assuming the package upgrade alone is sufficient.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.