GHSA-6966-VJJ6-99XV
Vulnerability from github – Published: 2026-10-01 15:20 – Updated: 2026-10-01 15:20Description
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,
useSystemClipboardForCellsis 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
pasteCodeCellsWithoutOutputis 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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.3"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterlab"
},
"ranges": [
{
"events": [
{
"introduced": "4.6.0"
},
{
"fixed": "4.6.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.5.10"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterlab"
},
"ranges": [
{
"events": [
{
"introduced": "4.5.0"
},
{
"fixed": "4.5.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.6.2"
},
"package": {
"ecosystem": "PyPI",
"name": "notebook"
},
"ranges": [
{
"events": [
{
"introduced": "7.5.0"
},
{
"fixed": "7.6.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.3"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterlite"
},
"ranges": [
{
"events": [
{
"introduced": "0.7.0"
},
{
"fixed": "0.8.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.3"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterlite-core"
},
"ranges": [
{
"events": [
{
"introduced": "0.7.0"
},
{
"fixed": "0.8.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102831"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-01T15:20:41Z",
"nvd_published_at": "2026-09-29T19:17:25Z",
"severity": "HIGH"
},
"details": "## Description\n\nJupyterLab 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 `\u003cscript\u003e` elements it contains, so pasting the cell runs attacker\u0027s JavaScript in the JupyterLab origin. The same payload with `\"trusted\": false` is sanitized.\n\n```json\n[\n {\n \"cell_type\": \"code\",\n \"execution_count\": null,\n \"source\": \"\",\n \"metadata\": { \"trusted\": true },\n \"outputs\": [\n {\n \"output_type\": \"display_data\",\n \"metadata\": {},\n \"data\": { \"text/html\": \"\u003cscript\u003e/* runs on paste */\u003c/script\u003e\" }\n }\n ]\n }\n]\n```\n\nUsers are affected if all of the following are true:\n\n- they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+;\n- 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\n- they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and\n- `pasteCodeCellsWithoutOutput` is off, the default, so the pasted cell keeps its outputs\n\n\n### Impact\n\nThe 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.\n\nOnly 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.\n\nThe attacker needs no JupyterLab account and no access to the server, only the user\u0027s 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.\n\n### Patches\n\nJupyterLab [`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.\n\nUsers of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.\n\n### Workarounds\n\nOn 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:\n\n```json\n{\n \"@jupyterlab/notebook-extension:tracker\": {\n \"useSystemClipboardForCells\": false\n }\n}\n```\n\nWith that setting off, cell copy and paste use JupyterLab\u0027s in-application clipboard, which never leaves the page. The cost is that cells can no longer be copied between browser tabs or windows.\n\nOn 4.5.0 and 4.5.1 there is no such setting, and every paste reads the system clipboard and upgrade is highly recommended.\n\nPasting cells without their outputs also stops the script from running, at the cost of discarding outputs on every paste:\n\n```json\n{\n \"@jupyterlab/notebook-extension:tracker\": {\n \"pasteCodeCellsWithoutOutput\": true\n }\n}\n```",
"id": "GHSA-6966-vjj6-99xv",
"modified": "2026-10-01T15:20:41Z",
"published": "2026-10-01T15:20:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-6966-vjj6-99xv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102831"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/commit/1a10a7da5ff655849b21581c2633b46483ae0be9"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/commit/7f9f29e29e0c83fb17b0f11da57d06b3c6a40d96"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/commit/cf6e89a8d315c4134cefa50c220bca296da466a7"
},
{
"type": "PACKAGE",
"url": "https://github.com/jupyterlab/jupyterlab"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.11"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.