CVE-2026-102831

highPriorität · verfolgen · 0OT-Risiko · erhöhtEPSS 0.002 · 9. PerzentilUS
grimoire priorityP2 · Scheduled
Exploitable?
—
no known exploitation
Likely / severe?
0.19% (9th) EPSS
CVSS 8.1 · high
Is it mine?
5 products
Prüfe deine Angriffsfläche
Who says so?
1 sources
osv

EPSS · bewertet 2026-10-27

JupyterLab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From JupyterLab 4.5.0 until 4.5.11 and 4.6.4, from Notebook 7.5.0 until 7.6.3, and from JupyterLite Core 0.7.0 until 0.8.4, the system clipboard cell-paste path accepts attacker-controlled cell JSON without clearing metadata.trusted. When useSystemClipboardForCells is active and pasteCodeCellsWithoutOutput is disabled, a pasted code cell can mark HTML output as trusted, bypass output sanitization, and execute script in the authenticated JupyterLab origin without executing the cell. Markdown and raw cells are not affected because their output is sanitized. This issue is fixed in JupyterLab 4.5.11 and 4.6.4, Notebook 7.6.3, and JupyterLite Core 0.8.4.

01

cvss

Technischer Schweregrad, 0–10. Eine Zeile je Quelle.

8.1
010

Basiswert 0–10 · höher = schwerwiegender · Vektor überfahren zum Auflösen

v3.18.1highCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:Nsecondary · security-advisories@github.comAusnutzbarkeit 2.8 · Auswirkung 5.2
v3.18.1highCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:Nsecondary · OSV
v3.17.4highCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N/E:Usecondary · CVSS-BT (t0sche)
02

SSVC

Eine Handlungsentscheidung — aus Ausnutzung und Auswirkung.

Exploitation: none · Automatable: no · Technical Impact: totalcoordinatorcisa_ssvcUS
03

schwächen

Die CWE-Schwächeklassen, zu denen dies gehört.

04

betroffene Produkte (5)

Betroffene Produkte und Versionsbereiche.

05

Advisories (5)

Hersteller- und Ökosystem-Meldungen dazu.

  • GHSA-6966-vjj6-99xvJupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard2026-10-01ghsa · osvUS

    ## Description JupyterLab 4.5.0 enabled copying and pasing cells through the system clipboard. The paste path parses clipboard text as cell JSON and inserts the cells without clearing `metadata.trusted`, so a payload can declare its own output as trusted. JupyterLab does not sanitize a trusted output and evaluates the `<script>` elements it contains, so pasting the cell runs attacker's JavaScript in the JupyterLab origin. The same payload with `"trusted": false` is sanitized. ```json [ { "cell_type": "code", "execution_count": null, "source": "", "metadata": { "trusted": true }, "outputs": [ { "output_type": "display_data", "metadata": {}, "data": { "text/html": "<script>/* runs on paste */</script>" } } ] } ] ``` Users are affected if all of the following are true: - they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - if running 4.5.2 or newer, `useSystemClipboardForCells` is enabled - it is off by default in 4.5.2+, and always enabled on 4.5.0 and 4.5.1 with no opt-out - they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and - `pasteCodeCellsWithoutOutput` is off, the default, so the pasted cell keeps its outputs ### Impact The script runs in the JupyterLab page, in the same origin and session as the authenticated user, so it can call the Jupyter Server REST API as that user: read and write any file under the server root, start a kernel and run code in it, and open a terminal where terminals are enabled. It runs on paste, without the user executing anything. Only the output of a code cell can run a script this way. Markdown and raw cells are always sanitized, as the [trust documentation](https://jupyterlab.readthedocs.io/en/latest/user/notebook.html#trust) states. The attacker needs no JupyterLab account and no access to the server, only the user's clipboard at the moment of the paste. A web page can replace the text you copy from it, or write the clipboard directly once you have given it permission. Both need you to click or press a key on that page first. ### Patches JupyterLab [`v4.6.4`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.4) and [`v4.5.11`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.11) contain the patch. Cells read from the system clipboard that cannot be traced to the current window no longer carry `metadata.trusted` into the notebook, so their outputs are sanitized like any other content of unknown origin. Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too. ### Workarounds On 4.5.2 and later, confirm that the system clipboard is not in use for cells. The setting is off by default; check Settings, Notebook, or the raw value: ```json { "@jupyterlab/notebook-extension:tracker": { "useSystemClipboardForCells": false } } ``` With that setting off, cell copy and paste use JupyterLab's in-application clipboard, which never leaves the page. The cost is that cells can no longer be copied between browser tabs or windows. On 4.5.0 and 4.5.1 there is no such setting, and every paste reads the system clipboard and upgrade is highly recommended. Pasting cells without their outputs also stops the script from running, at the cost of discarding outputs on every paste: ```json { "@jupyterlab/notebook-extension:tracker": { "pasteCodeCellsWithoutOutput": true } } ```

  • PYSEC-2026-4057JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard2026-10-01vendor · osvUS

    ## Description JupyterLab 4.5.0 enabled copying and pasing cells through the system clipboard. The paste path parses clipboard text as cell JSON and inserts the cells without clearing `metadata.trusted`, so a payload can declare its own output as trusted. JupyterLab does not sanitize a trusted output and evaluates the `<script>` elements it contains, so pasting the cell runs attacker's JavaScript in the JupyterLab origin. The same payload with `"trusted": false` is sanitized. ```json [ { "cell_type": "code", "execution_count": null, "source": "", "metadata": { "trusted": true }, "outputs": [ { "output_type": "display_data", "metadata": {}, "data": { "text/html": "<script>/* runs on paste */</script>" } } ] } ] ``` Users are affected if all of the following are true: - they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - if running 4.5.2 or newer, `useSystemClipboardForCells` is enabled - it is off by default in 4.5.2+, and always enabled on 4.5.0 and 4.5.1 with no opt-out - they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and - `pasteCodeCellsWithoutOutput` is off, the default, so the pasted cell keeps its outputs ### Impact The script runs in the JupyterLab page, in the same origin and session as the authenticated user, so it can call the Jupyter Server REST API as that user: read and write any file under the server root, start a kernel and run code in it, and open a terminal where terminals are enabled. It runs on paste, without the user executing anything. Only the output of a code cell can run a script this way. Markdown and raw cells are always sanitized, as the [trust documentation](https://jupyterlab.readthedocs.io/en/latest/user/notebook.html#trust) states. The attacker needs no JupyterLab account and no access to the server, only the user's clipboard at the moment of the paste. A web page can replace the text you copy from it, or write the clipboard directly once you have given it permission. Both need you to click or press a key on that page first. ### Patches JupyterLab [`v4.6.4`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.4) and [`v4.5.11`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.11) contain the patch. Cells read from the system clipboard that cannot be traced to the current window no longer carry `metadata.trusted` into the notebook, so their outputs are sanitized like any other content of unknown origin. Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too. ### Workarounds On 4.5.2 and later, confirm that the system clipboard is not in use for cells. The setting is off by default; check Settings, Notebook, or the raw value: ```json { "@jupyterlab/notebook-extension:tracker": { "useSystemClipboardForCells": false } } ``` With that setting off, cell copy and paste use JupyterLab's in-application clipboard, which never leaves the page. The cost is that cells can no longer be copied between browser tabs or windows. On 4.5.0 and 4.5.1 there is no such setting, and every paste reads the system clipboard and upgrade is highly recommended. Pasting cells without their outputs also stops the script from running, at the cost of discarding outputs on every paste: ```json { "@jupyterlab/notebook-extension:tracker": { "pasteCodeCellsWithoutOutput": true } } ```

  • PYSEC-2026-4058JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard2026-10-01vendor · osvUS

    ## Description JupyterLab 4.5.0 enabled copying and pasing cells through the system clipboard. The paste path parses clipboard text as cell JSON and inserts the cells without clearing `metadata.trusted`, so a payload can declare its own output as trusted. JupyterLab does not sanitize a trusted output and evaluates the `<script>` elements it contains, so pasting the cell runs attacker's JavaScript in the JupyterLab origin. The same payload with `"trusted": false` is sanitized. ```json [ { "cell_type": "code", "execution_count": null, "source": "", "metadata": { "trusted": true }, "outputs": [ { "output_type": "display_data", "metadata": {}, "data": { "text/html": "<script>/* runs on paste */</script>" } } ] } ] ``` Users are affected if all of the following are true: - they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - if running 4.5.2 or newer, `useSystemClipboardForCells` is enabled - it is off by default in 4.5.2+, and always enabled on 4.5.0 and 4.5.1 with no opt-out - they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and - `pasteCodeCellsWithoutOutput` is off, the default, so the pasted cell keeps its outputs ### Impact The script runs in the JupyterLab page, in the same origin and session as the authenticated user, so it can call the Jupyter Server REST API as that user: read and write any file under the server root, start a kernel and run code in it, and open a terminal where terminals are enabled. It runs on paste, without the user executing anything. Only the output of a code cell can run a script this way. Markdown and raw cells are always sanitized, as the [trust documentation](https://jupyterlab.readthedocs.io/en/latest/user/notebook.html#trust) states. The attacker needs no JupyterLab account and no access to the server, only the user's clipboard at the moment of the paste. A web page can replace the text you copy from it, or write the clipboard directly once you have given it permission. Both need you to click or press a key on that page first. ### Patches JupyterLab [`v4.6.4`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.4) and [`v4.5.11`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.11) contain the patch. Cells read from the system clipboard that cannot be traced to the current window no longer carry `metadata.trusted` into the notebook, so their outputs are sanitized like any other content of unknown origin. Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too. ### Workarounds On 4.5.2 and later, confirm that the system clipboard is not in use for cells. The setting is off by default; check Settings, Notebook, or the raw value: ```json { "@jupyterlab/notebook-extension:tracker": { "useSystemClipboardForCells": false } } ``` With that setting off, cell copy and paste use JupyterLab's in-application clipboard, which never leaves the page. The cost is that cells can no longer be copied between browser tabs or windows. On 4.5.0 and 4.5.1 there is no such setting, and every paste reads the system clipboard and upgrade is highly recommended. Pasting cells without their outputs also stops the script from running, at the cost of discarding outputs on every paste: ```json { "@jupyterlab/notebook-extension:tracker": { "pasteCodeCellsWithoutOutput": true } } ```

  • PYSEC-2026-4060JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard2026-10-01vendor · osvUS

    ## Description JupyterLab 4.5.0 enabled copying and pasing cells through the system clipboard. The paste path parses clipboard text as cell JSON and inserts the cells without clearing `metadata.trusted`, so a payload can declare its own output as trusted. JupyterLab does not sanitize a trusted output and evaluates the `<script>` elements it contains, so pasting the cell runs attacker's JavaScript in the JupyterLab origin. The same payload with `"trusted": false` is sanitized. ```json [ { "cell_type": "code", "execution_count": null, "source": "", "metadata": { "trusted": true }, "outputs": [ { "output_type": "display_data", "metadata": {}, "data": { "text/html": "<script>/* runs on paste */</script>" } } ] } ] ``` Users are affected if all of the following are true: - they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - if running 4.5.2 or newer, `useSystemClipboardForCells` is enabled - it is off by default in 4.5.2+, and always enabled on 4.5.0 and 4.5.1 with no opt-out - they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and - `pasteCodeCellsWithoutOutput` is off, the default, so the pasted cell keeps its outputs ### Impact The script runs in the JupyterLab page, in the same origin and session as the authenticated user, so it can call the Jupyter Server REST API as that user: read and write any file under the server root, start a kernel and run code in it, and open a terminal where terminals are enabled. It runs on paste, without the user executing anything. Only the output of a code cell can run a script this way. Markdown and raw cells are always sanitized, as the [trust documentation](https://jupyterlab.readthedocs.io/en/latest/user/notebook.html#trust) states. The attacker needs no JupyterLab account and no access to the server, only the user's clipboard at the moment of the paste. A web page can replace the text you copy from it, or write the clipboard directly once you have given it permission. Both need you to click or press a key on that page first. ### Patches JupyterLab [`v4.6.4`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.4) and [`v4.5.11`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.11) contain the patch. Cells read from the system clipboard that cannot be traced to the current window no longer carry `metadata.trusted` into the notebook, so their outputs are sanitized like any other content of unknown origin. Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too. ### Workarounds On 4.5.2 and later, confirm that the system clipboard is not in use for cells. The setting is off by default; check Settings, Notebook, or the raw value: ```json { "@jupyterlab/notebook-extension:tracker": { "useSystemClipboardForCells": false } } ``` With that setting off, cell copy and paste use JupyterLab's in-application clipboard, which never leaves the page. The cost is that cells can no longer be copied between browser tabs or windows. On 4.5.0 and 4.5.1 there is no such setting, and every paste reads the system clipboard and upgrade is highly recommended. Pasting cells without their outputs also stops the script from running, at the cost of discarding outputs on every paste: ```json { "@jupyterlab/notebook-extension:tracker": { "pasteCodeCellsWithoutOutput": true } } ```

  • PYSEC-2026-4112JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard2026-10-01vendor · osvUS

    ## Description JupyterLab 4.5.0 enabled copying and pasing cells through the system clipboard. The paste path parses clipboard text as cell JSON and inserts the cells without clearing `metadata.trusted`, so a payload can declare its own output as trusted. JupyterLab does not sanitize a trusted output and evaluates the `<script>` elements it contains, so pasting the cell runs attacker's JavaScript in the JupyterLab origin. The same payload with `"trusted": false` is sanitized. ```json [ { "cell_type": "code", "execution_count": null, "source": "", "metadata": { "trusted": true }, "outputs": [ { "output_type": "display_data", "metadata": {}, "data": { "text/html": "<script>/* runs on paste */</script>" } } ] } ] ``` Users are affected if all of the following are true: - they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - if running 4.5.2 or newer, `useSystemClipboardForCells` is enabled - it is off by default in 4.5.2+, and always enabled on 4.5.0 and 4.5.1 with no opt-out - they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and - `pasteCodeCellsWithoutOutput` is off, the default, so the pasted cell keeps its outputs ### Impact The script runs in the JupyterLab page, in the same origin and session as the authenticated user, so it can call the Jupyter Server REST API as that user: read and write any file under the server root, start a kernel and run code in it, and open a terminal where terminals are enabled. It runs on paste, without the user executing anything. Only the output of a code cell can run a script this way. Markdown and raw cells are always sanitized, as the [trust documentation](https://jupyterlab.readthedocs.io/en/latest/user/notebook.html#trust) states. The attacker needs no JupyterLab account and no access to the server, only the user's clipboard at the moment of the paste. A web page can replace the text you copy from it, or write the clipboard directly once you have given it permission. Both need you to click or press a key on that page first. ### Patches JupyterLab [`v4.6.4`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.4) and [`v4.5.11`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.11) contain the patch. Cells read from the system clipboard that cannot be traced to the current window no longer carry `metadata.trusted` into the notebook, so their outputs are sanitized like any other content of unknown origin. Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too. ### Workarounds On 4.5.2 and later, confirm that the system clipboard is not in use for cells. The setting is off by default; check Settings, Notebook, or the raw value: ```json { "@jupyterlab/notebook-extension:tracker": { "useSystemClipboardForCells": false } } ``` With that setting off, cell copy and paste use JupyterLab's in-application clipboard, which never leaves the page. The cost is that cells can no longer be copied between browser tabs or windows. On 4.5.0 and 4.5.1 there is no such setting, and every paste reads the system clipboard and upgrade is highly recommended. Pasting cells without their outputs also stops the script from running, at the cost of discarding outputs on every paste: ```json { "@jupyterlab/notebook-extension:tracker": { "pasteCodeCellsWithoutOutput": true } } ```

06

auch bekannt als (5)

Weitere Namen und Kennungen dieser Entität.

07

quellen

Welche Quellen diesen Datensatz belegen und wann.

veröffentlicht 2026-09-29geändert 2026-10-02
08

Referenzen (6) nvd

Externe Belege — Patches, Meldungen, Analysen.

scry

Angreifer nutzen Schwachstellen wie diese gegen im Internet exponierte Dienste aus. Sehen Sie mit einem kostenlosen Passiv-Scan, was exponiert ist.

Kostenloser Scan