Came across something in uv.lock around line 1 that looked worth flagging.
The HTML sanitizer in JupyterLab < 4.5.7 incorrectly allowlists the data‑commandlinker‑command and data‑commandlinker‑args attributes on button elements. CommandLinker listens for all click events on document.body and executes the referenced command without checking if the element came from trusted JupyterLab UI. An attacker can embed a malicious HTML cell output with a deceptive button, triggering arbitrary JupyterLab commands (including arbitrary code execution) on a single user click, even though no user‑submitted code is executed. This is a high‑severity (critical) vulnerability.
Something like this might fix it:
--- a/uv.lock
+++ b/uv.lock
@@ -1,4 +1,4 @@
[[package]]
name = "jupyterlab"
-version = "4.5.6"
+version = "4.5.7"
For reference: rule CVE-2026-42557. Rated critical.
If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Came across something in
uv.lockaround line 1 that looked worth flagging.The HTML sanitizer in JupyterLab < 4.5.7 incorrectly allowlists the data‑commandlinker‑command and data‑commandlinker‑args attributes on button elements. CommandLinker listens for all click events on document.body and executes the referenced command without checking if the element came from trusted JupyterLab UI. An attacker can embed a malicious HTML cell output with a deceptive button, triggering arbitrary JupyterLab commands (including arbitrary code execution) on a single user click, even though no user‑submitted code is executed. This is a high‑severity (critical) vulnerability.
Something like this might fix it:
For reference: rule
CVE-2026-42557. Rated critical.If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.