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

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.