GPU VulnDB

Database/AI/ML frameworks & serving

JupyterLab: crafted SVG in the image viewer yields same-origin XSS and code execution on the server

CVSS 7.5CVE-2026-73415AI/ML frameworks & servingcurated

Impact

The image viewer creates a blob URL for an SVG and revokes it too early, so opening that image and then opening it in a new browser tab leaves it running in JupyterLab's own origin. From there the script can drive the Jupyter server API as the logged-in user, which on a notebook server means executing arbitrary code in that user's kernel - i.e. on the GPU node the kernel runs on. This is the standard notebook-server escalation path: an attacker who can place a file in a shared dataset or scratch directory, or hand a user a repo to open, gets code execution on the accelerator node rather than just a browser popup. It needs the user to open the image and then open it in a new tab, which is why the record scores it as requiring user interaction.

Who can reach it

Anyone who can get a crafted SVG into a directory a JupyterLab user browses - a shared /scratch or dataset mount, a cloned repo, an uploaded file. The victim must open the image in the viewer and then open it in a new tab; the attacker needs no JupyterLab account.

What to do

Upgrade JupyterLab to 4.5.10 or 4.6.2 and restart the notebook servers - per-user or per-pod restart of the Jupyter process, which interrupts running kernels but requires no node drain. Rebuild any notebook container images that pin an older JupyterLab.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73415https://github.com/jupyterlab/jupyterlab/commit/9365f020baec5221deaf11535ed554c06637c999https://github.com/jupyterlab/jupyterlab/pull/19184https://github.com/jupyterlab/jupyterlab/pull/19185

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.