jupyterlite

Version	Released
`0.9.0b0` pre	Oct 29, 2026
`0.8.6` patch	Oct 07, 2026
`0.8.5` patch	Sep 28, 2026
`0.9.0a2` pre	Sep 24, 2026
`0.8.4` patch	Sep 22, 2026
`0.8.3` patch 1 CVE	Aug 20, 2026
`0.8.2` patch 1 CVE	Aug 17, 2026
`0.9.0a1` pre	Aug 03, 2026
`0.9.0a0` pre	Jul 10, 2026
`0.8.1` patch 1 CVE	Jul 08, 2026
`0.8.0` minor 1 CVE	Jun 23, 2026
`0.8.0rc0` pre 1 CVE	Jun 18, 2026
`0.8.0b1` pre 1 CVE	Jun 02, 2026
`0.8.0b0` pre 1 CVE	May 21, 2026
`0.7.6` patch 1 CVE	May 07, 2026
`0.7.5` patch 1 CVE	May 04, 2026
`0.8.0a2` pre 1 CVE	May 04, 2026
`0.7.4` patch 1 CVE	Mar 12, 2026
`0.7.3` patch 1 CVE	Feb 25, 2026
`0.7.2` patch 1 CVE	Feb 23, 2026
`0.8.0a1` pre 1 CVE	Jan 26, 2026
`0.8.0a0` pre 1 CVE	Dec 19, 2025
`0.7.1` patch 1 CVE	Dec 16, 2025
`0.7.0` minor 1 CVE	Nov 26, 2025
`0.7.0rc2` pre	Nov 25, 2025
`0.7.0rc1` pre	Nov 21, 2025
`0.7.0rc0` pre	Nov 19, 2025
`0.7.0b1` pre	Nov 04, 2025
`0.7.0b0` pre	Oct 23, 2025
`0.7.0a7` pre	Oct 10, 2025
`0.7.0a6` pre	Sep 24, 2025
`0.7.0a5` pre	Sep 08, 2025
`0.7.0a4` pre	Aug 19, 2025
`0.7.0a3` pre	Aug 13, 2025
`0.7.0a2` pre	Aug 11, 2025
`0.6.4` patch	Aug 08, 2025
`0.7.0a1` pre	Aug 05, 2025
`0.7.0a0` pre	Jul 03, 2025
`0.6.3` patch	Jun 30, 2025
`0.6.2` patch	Jun 16, 2025
`0.6.1` patch	Jun 05, 2025
`0.6.0` minor	Jun 02, 2025
`0.6.0rc0` pre	May 27, 2025
`0.6.0b1` pre	May 21, 2025
`0.6.0b0` pre	May 12, 2025
`0.6.0a10` pre	May 08, 2025
`0.6.0a9` pre	Apr 18, 2025
`0.6.0a8` pre	Apr 15, 2025
`0.6.0a7` pre	Mar 31, 2025
`0.6.0a6` pre	Mar 27, 2025

0.9.0b0 pre

Oct 29, 2026

0.8.6 patch

Oct 07, 2026

0.8.5 patch

Sep 28, 2026

0.9.0a2 pre

Sep 24, 2026

0.8.4 patch

Sep 22, 2026

0.8.3 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Aug 20, 2026

0.8.2 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Aug 17, 2026

0.9.0a1 pre

Aug 03, 2026

0.9.0a0 pre

Jul 10, 2026

0.8.1 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Jul 08, 2026

0.8.0 minor

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Jun 23, 2026

0.8.0rc0 pre

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Jun 18, 2026

0.8.0b1 pre

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Jun 02, 2026

0.8.0b0 pre

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

May 21, 2026

0.7.6 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

May 07, 2026

0.7.5 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

May 04, 2026

0.8.0a2 pre

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

May 04, 2026

0.7.4 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Mar 12, 2026

0.7.3 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Feb 25, 2026

0.7.2 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Feb 23, 2026

0.8.0a1 pre

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Jan 26, 2026

0.8.0a0 pre

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Dec 19, 2025

0.7.1 patch

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Dec 16, 2025

0.7.0 minor

1 CVE

CVE-2026-102831 PYSEC-2026-4058 GHSA-6966-vjj6-99xv PYSEC-2026-4057 PYSEC-2026-4060 PYSEC-2026-4112 Oct 01, 2026

JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard

8.1 / 10

High

Network Low None Required Unchanged High High None

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.

[
  {
    "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 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 and 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:

{
  "@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:

{
  "@jupyterlab/notebook-extension:tracker": {
    "pasteCodeCellsWithoutOutput": true
  }
}

Affected versions


          0.7.0


          0.7.1


          0.7.2


          0.7.3


          0.7.4


          0.7.5


          0.7.6


          0.8.0


          0.8.0a0


          0.8.0a1


          0.8.0a2


          0.8.0b0

+ 5 more


            0.8.0b1


            0.8.0rc0


            0.8.1


            0.8.2


            0.8.3

Fixed in


          0.8.4

References

Updated Oct 01, 2026 · Source: OSV.dev

Nov 26, 2025

0.7.0rc2 pre

Nov 25, 2025

0.7.0rc1 pre

Nov 21, 2025

0.7.0rc0 pre

Nov 19, 2025

0.7.0b1 pre

Nov 04, 2025

0.7.0b0 pre

Oct 23, 2025

0.7.0a7 pre

Oct 10, 2025

0.7.0a6 pre

Sep 24, 2025

0.7.0a5 pre

Sep 08, 2025

0.7.0a4 pre

Aug 19, 2025

0.7.0a3 pre

Aug 13, 2025

0.7.0a2 pre

Aug 11, 2025

0.6.4 patch

Aug 08, 2025

0.7.0a1 pre

Aug 05, 2025

0.7.0a0 pre

Jul 03, 2025

0.6.3 patch

Jun 30, 2025

0.6.2 patch

Jun 16, 2025

0.6.1 patch

Jun 05, 2025

0.6.0 minor

Jun 02, 2025

0.6.0rc0 pre

May 27, 2025

0.6.0b1 pre

May 21, 2025

0.6.0b0 pre

May 12, 2025

0.6.0a10 pre

May 08, 2025

0.6.0a9 pre

Apr 18, 2025

0.6.0a8 pre

Apr 15, 2025

0.6.0a7 pre

Mar 31, 2025

0.6.0a6 pre

Mar 27, 2025

Activity

Reach

Details