<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from pysec</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 09:40:29 +0000</lastBuildDate>
    <item>
      <title>PYSEC-2026-4059 — JupyterLab: Cross-site scripting (XSS) in JupyterLab via crafted language package (jupyterlab.json)</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4059</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlite-core&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;A language pack ships a `Plural-Forms` header saying how the language counts, for example `nplurals=2; plural=(n != 1);`. JupyterLab turns that string into a function with `new Function`, so the header gets executed. The check that meant to keep it safe was a regular expression. The regex was anchored at the start but not at the end, so it accepted any string that began with a valid plural rule and ignored everything after it.&lt;/p&gt;
&lt;p&gt;A header such as the following passed the check, and the part after the plural rule ran in the JupyterLab page as soon as the first plural string was translated:&lt;/p&gt;
&lt;p&gt;```
nplurals=2; plural=(n &amp;gt; 1); &amp;lt;anything here ran as JavaScript&amp;gt;
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- they run JupyterLab 3.0.0 through 4.6.3, or an application that bundles it such as Notebook 7;
- a language pack they did not write is installed in the environment; and
- that language is selected, so its catalogue is loaded&lt;/p&gt;
&lt;p&gt;An installation using the default English locale loads no catalogue and is not affected.&lt;/p&gt;
&lt;p&gt;&amp;gt; CVE assignment pending, GitHub CNA is experiencing severe backlog&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The code in the header ran in the JupyterLab page, in the same origin and session as the authenticated user. It could 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. Nothing had to be clicked; translating one plural string was enough,…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlite-core&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;A language pack ships a `Plural-Forms` header saying how the language counts, for example `nplurals=2; plural=(n != 1);`. JupyterLab turns that string into a function with `new Function`, so the header gets executed. The check that meant to keep it safe was a regular expression. The regex was anchored at the start but not at the end, so it accepted any string that began with a valid plural rule and ignored everything after it.&lt;/p&gt;
&lt;p&gt;A header such as the following passed the check, and the part after the plural rule ran in the JupyterLab page as soon as the first plural string was translated:&lt;/p&gt;
&lt;p&gt;```
nplurals=2; plural=(n &amp;gt; 1); &amp;lt;anything here ran as JavaScript&amp;gt;
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- they run JupyterLab 3.0.0 through 4.6.3, or an application that bundles it such as Notebook 7;
- a language pack they did not write is installed in the environment; and
- that language is selected, so its catalogue is loaded&lt;/p&gt;
&lt;p&gt;An installation using the default English locale loads no catalogue and is not affected.&lt;/p&gt;
&lt;p&gt;&amp;gt; CVE assignment pending, GitHub CNA is experiencing severe backlog&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The code in the header ran in the JupyterLab page, in the same origin and session as the authenticated user. It could 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. Nothing had to be clicked; translating one plural string was enough,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4059</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:34 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4056 — JupyterLab: Cross-site scripting (XSS) in JupyterLab via crafted language package (jupyterlab.json)</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4056</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlab&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;A language pack ships a `Plural-Forms` header saying how the language counts, for example `nplurals=2; plural=(n != 1);`. JupyterLab turns that string into a function with `new Function`, so the header gets executed. The check that meant to keep it safe was a regular expression. The regex was anchored at the start but not at the end, so it accepted any string that began with a valid plural rule and ignored everything after it.&lt;/p&gt;
&lt;p&gt;A header such as the following passed the check, and the part after the plural rule ran in the JupyterLab page as soon as the first plural string was translated:&lt;/p&gt;
&lt;p&gt;```
nplurals=2; plural=(n &amp;gt; 1); &amp;lt;anything here ran as JavaScript&amp;gt;
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- they run JupyterLab 3.0.0 through 4.6.3, or an application that bundles it such as Notebook 7;
- a language pack they did not write is installed in the environment; and
- that language is selected, so its catalogue is loaded&lt;/p&gt;
&lt;p&gt;An installation using the default English locale loads no catalogue and is not affected.&lt;/p&gt;
&lt;p&gt;&amp;gt; CVE assignment pending, GitHub CNA is experiencing severe backlog&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The code in the header ran in the JupyterLab page, in the same origin and session as the authenticated user. It could 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. Nothing had to be clicked; translating one plural string was enough,…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlab&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;A language pack ships a `Plural-Forms` header saying how the language counts, for example `nplurals=2; plural=(n != 1);`. JupyterLab turns that string into a function with `new Function`, so the header gets executed. The check that meant to keep it safe was a regular expression. The regex was anchored at the start but not at the end, so it accepted any string that began with a valid plural rule and ignored everything after it.&lt;/p&gt;
&lt;p&gt;A header such as the following passed the check, and the part after the plural rule ran in the JupyterLab page as soon as the first plural string was translated:&lt;/p&gt;
&lt;p&gt;```
nplurals=2; plural=(n &amp;gt; 1); &amp;lt;anything here ran as JavaScript&amp;gt;
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- they run JupyterLab 3.0.0 through 4.6.3, or an application that bundles it such as Notebook 7;
- a language pack they did not write is installed in the environment; and
- that language is selected, so its catalogue is loaded&lt;/p&gt;
&lt;p&gt;An installation using the default English locale loads no catalogue and is not affected.&lt;/p&gt;
&lt;p&gt;&amp;gt; CVE assignment pending, GitHub CNA is experiencing severe backlog&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The code in the header ran in the JupyterLab page, in the same origin and session as the authenticated user. It could 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. Nothing had to be clicked; translating one plural string was enough,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4056</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:34 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4055 — JupyterLab: Argument injection in JupyterLab extension uninstall exposes server-readable files and internal URLs</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4055</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlab&lt;/p&gt;
&lt;p&gt;JupyterLab&amp;#39;s PyPI extension manager runs `python -m pip uninstall` with the extension name taken from the request body. `ExtensionHandler.post` validates the name for `cmd=install` but not for `cmd=uninstall`, so a name that begins with `-` reaches the command line and pip reads it as an option rather than as a package.&lt;/p&gt;
&lt;p&gt;```python
cmdline = [
    sys.executable,
    &amp;#34;-m&amp;#34;,
    &amp;#34;pip&amp;#34;,
    &amp;#34;uninstall&amp;#34;,
    &amp;#34;--yes&amp;#34;,
    &amp;#34;--no-input&amp;#34;,
    extension,
]
```&lt;/p&gt;
&lt;p&gt;An extension name of the form `-r` followed by a path therefore made pip open that path as a requirements file. pip&amp;#39;s parse error quotes the line it could not read and names the file it came from, and JupyterLab returned that error in the response body, so the line reached the requester.&lt;/p&gt;
&lt;p&gt;This has security implications only for deployments that combine all of the following:&lt;/p&gt;
&lt;p&gt;- the (default) PyPI Extension Manager enabled, so that uninstall requests reach pip;
- an authenticated account permitted to call the extension API; and
- kernels and terminals disabled or delegated to remote hosts (otherwise a user with kernel access can read the same files and make the same outbound requests directly, regardless of this endpoint)&lt;/p&gt;
&lt;p&gt;Unlike [GHSA-37w4-hwhx-4rc4](https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-37w4-hwhx-4rc4) and [GHSA-89vp-jrxv-24w8](https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-89vp-jrxv-24w8), this does not need an allowlist or blocklist to be configured. The uninstall path never cons…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlab&lt;/p&gt;
&lt;p&gt;JupyterLab&amp;#39;s PyPI extension manager runs `python -m pip uninstall` with the extension name taken from the request body. `ExtensionHandler.post` validates the name for `cmd=install` but not for `cmd=uninstall`, so a name that begins with `-` reaches the command line and pip reads it as an option rather than as a package.&lt;/p&gt;
&lt;p&gt;```python
cmdline = [
    sys.executable,
    &amp;#34;-m&amp;#34;,
    &amp;#34;pip&amp;#34;,
    &amp;#34;uninstall&amp;#34;,
    &amp;#34;--yes&amp;#34;,
    &amp;#34;--no-input&amp;#34;,
    extension,
]
```&lt;/p&gt;
&lt;p&gt;An extension name of the form `-r` followed by a path therefore made pip open that path as a requirements file. pip&amp;#39;s parse error quotes the line it could not read and names the file it came from, and JupyterLab returned that error in the response body, so the line reached the requester.&lt;/p&gt;
&lt;p&gt;This has security implications only for deployments that combine all of the following:&lt;/p&gt;
&lt;p&gt;- the (default) PyPI Extension Manager enabled, so that uninstall requests reach pip;
- an authenticated account permitted to call the extension API; and
- kernels and terminals disabled or delegated to remote hosts (otherwise a user with kernel access can read the same files and make the same outbound requests directly, regardless of this endpoint)&lt;/p&gt;
&lt;p&gt;Unlike [GHSA-37w4-hwhx-4rc4](https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-37w4-hwhx-4rc4) and [GHSA-89vp-jrxv-24w8](https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-89vp-jrxv-24w8), this does not need an allowlist or blocklist to be configured. The uninstall path never cons…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4055</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:34 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4060 — JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4060</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlite-core&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;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 `&amp;lt;script&amp;gt;` elements it contains, so pasting the cell runs attacker&amp;#39;s JavaScript in the JupyterLab origin. The same payload with `&amp;#34;trusted&amp;#34;: false` is sanitized.&lt;/p&gt;
&lt;p&gt;```json
[
  {
    &amp;#34;cell_type&amp;#34;: &amp;#34;code&amp;#34;,
    &amp;#34;execution_count&amp;#34;: null,
    &amp;#34;source&amp;#34;: &amp;#34;&amp;#34;,
    &amp;#34;metadata&amp;#34;: { &amp;#34;trusted&amp;#34;: true },
    &amp;#34;outputs&amp;#34;: [
      {
        &amp;#34;output_type&amp;#34;: &amp;#34;display_data&amp;#34;,
        &amp;#34;metadata&amp;#34;: {},
        &amp;#34;data&amp;#34;: { &amp;#34;text/html&amp;#34;: &amp;#34;&amp;lt;script&amp;gt;/* runs on paste */&amp;lt;/script&amp;gt;&amp;#34; }
      }
    ]
  }
]
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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 use…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlite-core&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;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 `&amp;lt;script&amp;gt;` elements it contains, so pasting the cell runs attacker&amp;#39;s JavaScript in the JupyterLab origin. The same payload with `&amp;#34;trusted&amp;#34;: false` is sanitized.&lt;/p&gt;
&lt;p&gt;```json
[
  {
    &amp;#34;cell_type&amp;#34;: &amp;#34;code&amp;#34;,
    &amp;#34;execution_count&amp;#34;: null,
    &amp;#34;source&amp;#34;: &amp;#34;&amp;#34;,
    &amp;#34;metadata&amp;#34;: { &amp;#34;trusted&amp;#34;: true },
    &amp;#34;outputs&amp;#34;: [
      {
        &amp;#34;output_type&amp;#34;: &amp;#34;display_data&amp;#34;,
        &amp;#34;metadata&amp;#34;: {},
        &amp;#34;data&amp;#34;: { &amp;#34;text/html&amp;#34;: &amp;#34;&amp;lt;script&amp;gt;/* runs on paste */&amp;lt;/script&amp;gt;&amp;#34; }
      }
    ]
  }
]
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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 use…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4060</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:34 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4058 — JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4058</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlite&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;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 `&amp;lt;script&amp;gt;` elements it contains, so pasting the cell runs attacker&amp;#39;s JavaScript in the JupyterLab origin. The same payload with `&amp;#34;trusted&amp;#34;: false` is sanitized.&lt;/p&gt;
&lt;p&gt;```json
[
  {
    &amp;#34;cell_type&amp;#34;: &amp;#34;code&amp;#34;,
    &amp;#34;execution_count&amp;#34;: null,
    &amp;#34;source&amp;#34;: &amp;#34;&amp;#34;,
    &amp;#34;metadata&amp;#34;: { &amp;#34;trusted&amp;#34;: true },
    &amp;#34;outputs&amp;#34;: [
      {
        &amp;#34;output_type&amp;#34;: &amp;#34;display_data&amp;#34;,
        &amp;#34;metadata&amp;#34;: {},
        &amp;#34;data&amp;#34;: { &amp;#34;text/html&amp;#34;: &amp;#34;&amp;lt;script&amp;gt;/* runs on paste */&amp;lt;/script&amp;gt;&amp;#34; }
      }
    ]
  }
]
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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 use…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlite&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;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 `&amp;lt;script&amp;gt;` elements it contains, so pasting the cell runs attacker&amp;#39;s JavaScript in the JupyterLab origin. The same payload with `&amp;#34;trusted&amp;#34;: false` is sanitized.&lt;/p&gt;
&lt;p&gt;```json
[
  {
    &amp;#34;cell_type&amp;#34;: &amp;#34;code&amp;#34;,
    &amp;#34;execution_count&amp;#34;: null,
    &amp;#34;source&amp;#34;: &amp;#34;&amp;#34;,
    &amp;#34;metadata&amp;#34;: { &amp;#34;trusted&amp;#34;: true },
    &amp;#34;outputs&amp;#34;: [
      {
        &amp;#34;output_type&amp;#34;: &amp;#34;display_data&amp;#34;,
        &amp;#34;metadata&amp;#34;: {},
        &amp;#34;data&amp;#34;: { &amp;#34;text/html&amp;#34;: &amp;#34;&amp;lt;script&amp;gt;/* runs on paste */&amp;lt;/script&amp;gt;&amp;#34; }
      }
    ]
  }
]
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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 use…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4058</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:34 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4112 — JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4112</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: notebook&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;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 `&amp;lt;script&amp;gt;` elements it contains, so pasting the cell runs attacker&amp;#39;s JavaScript in the JupyterLab origin. The same payload with `&amp;#34;trusted&amp;#34;: false` is sanitized.&lt;/p&gt;
&lt;p&gt;```json
[
  {
    &amp;#34;cell_type&amp;#34;: &amp;#34;code&amp;#34;,
    &amp;#34;execution_count&amp;#34;: null,
    &amp;#34;source&amp;#34;: &amp;#34;&amp;#34;,
    &amp;#34;metadata&amp;#34;: { &amp;#34;trusted&amp;#34;: true },
    &amp;#34;outputs&amp;#34;: [
      {
        &amp;#34;output_type&amp;#34;: &amp;#34;display_data&amp;#34;,
        &amp;#34;metadata&amp;#34;: {},
        &amp;#34;data&amp;#34;: { &amp;#34;text/html&amp;#34;: &amp;#34;&amp;lt;script&amp;gt;/* runs on paste */&amp;lt;/script&amp;gt;&amp;#34; }
      }
    ]
  }
]
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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 use…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: notebook&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;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 `&amp;lt;script&amp;gt;` elements it contains, so pasting the cell runs attacker&amp;#39;s JavaScript in the JupyterLab origin. The same payload with `&amp;#34;trusted&amp;#34;: false` is sanitized.&lt;/p&gt;
&lt;p&gt;```json
[
  {
    &amp;#34;cell_type&amp;#34;: &amp;#34;code&amp;#34;,
    &amp;#34;execution_count&amp;#34;: null,
    &amp;#34;source&amp;#34;: &amp;#34;&amp;#34;,
    &amp;#34;metadata&amp;#34;: { &amp;#34;trusted&amp;#34;: true },
    &amp;#34;outputs&amp;#34;: [
      {
        &amp;#34;output_type&amp;#34;: &amp;#34;display_data&amp;#34;,
        &amp;#34;metadata&amp;#34;: {},
        &amp;#34;data&amp;#34;: { &amp;#34;text/html&amp;#34;: &amp;#34;&amp;lt;script&amp;gt;/* runs on paste */&amp;lt;/script&amp;gt;&amp;#34; }
      }
    ]
  }
]
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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 use…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4112</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:34 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4057 — JupyterLab: Cross-site scripting (XSS) in JupyterLab via notebook cells pasted from the system clipboard</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4057</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlab&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;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 `&amp;lt;script&amp;gt;` elements it contains, so pasting the cell runs attacker&amp;#39;s JavaScript in the JupyterLab origin. The same payload with `&amp;#34;trusted&amp;#34;: false` is sanitized.&lt;/p&gt;
&lt;p&gt;```json
[
  {
    &amp;#34;cell_type&amp;#34;: &amp;#34;code&amp;#34;,
    &amp;#34;execution_count&amp;#34;: null,
    &amp;#34;source&amp;#34;: &amp;#34;&amp;#34;,
    &amp;#34;metadata&amp;#34;: { &amp;#34;trusted&amp;#34;: true },
    &amp;#34;outputs&amp;#34;: [
      {
        &amp;#34;output_type&amp;#34;: &amp;#34;display_data&amp;#34;,
        &amp;#34;metadata&amp;#34;: {},
        &amp;#34;data&amp;#34;: { &amp;#34;text/html&amp;#34;: &amp;#34;&amp;lt;script&amp;gt;/* runs on paste */&amp;lt;/script&amp;gt;&amp;#34; }
      }
    ]
  }
]
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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 use…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: jupyterlab&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;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 `&amp;lt;script&amp;gt;` elements it contains, so pasting the cell runs attacker&amp;#39;s JavaScript in the JupyterLab origin. The same payload with `&amp;#34;trusted&amp;#34;: false` is sanitized.&lt;/p&gt;
&lt;p&gt;```json
[
  {
    &amp;#34;cell_type&amp;#34;: &amp;#34;code&amp;#34;,
    &amp;#34;execution_count&amp;#34;: null,
    &amp;#34;source&amp;#34;: &amp;#34;&amp;#34;,
    &amp;#34;metadata&amp;#34;: { &amp;#34;trusted&amp;#34;: true },
    &amp;#34;outputs&amp;#34;: [
      {
        &amp;#34;output_type&amp;#34;: &amp;#34;display_data&amp;#34;,
        &amp;#34;metadata&amp;#34;: {},
        &amp;#34;data&amp;#34;: { &amp;#34;text/html&amp;#34;: &amp;#34;&amp;lt;script&amp;gt;/* runs on paste */&amp;lt;/script&amp;gt;&amp;#34; }
      }
    ]
  }
]
```&lt;/p&gt;
&lt;p&gt;Users are affected if all of the following are true:&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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 use…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4057</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:34 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4159 — pypdf: Possible long runtimes with large amount of embedded files</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4159</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pypdf&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing the embedded files through the dictionary-based API.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If you cannot upgrade yet, consider applying the changes from PR [#4081](https://github.com/py-pdf/pypdf/pull/4081).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pypdf&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing the embedded files through the dictionary-based API.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If you cannot upgrade yet, consider applying the changes from PR [#4081](https://github.com/py-pdf/pypdf/pull/4081).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4159</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:33 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4157 — pypdf: Possible long runtimes when generating appearance streams</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4157</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pypdf&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires updating form field values with flattening enabled, which triggers appearance stream generation.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If you cannot upgrade yet, consider applying the changes from PR [#4087](https://github.com/py-pdf/pypdf/pull/4087).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pypdf&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires updating form field values with flattening enabled, which triggers appearance stream generation.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If you cannot upgrade yet, consider applying the changes from PR [#4087](https://github.com/py-pdf/pypdf/pull/4087).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4157</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:33 +0000</pubDate>
    </item>
    <item>
      <title>PYSEC-2026-4160 — pypdf: Possible large memory usage when retrieving alphabetical page labels</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-4160</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pypdf&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An attacker who uses this vulnerability can craft a PDF which leads to large memory consumption. This requires accessing the page labels of a document with large alphabetical labels.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If you cannot upgrade yet, consider applying the changes from PR [#4096](https://github.com/py-pdf/pypdf/pull/4096).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pypdf&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An attacker who uses this vulnerability can craft a PDF which leads to large memory consumption. This requires accessing the page labels of a document with large alphabetical labels.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;This has been fixed in [pypdf==6.19.0](https://github.com/py-pdf/pypdf/releases/tag/6.19.0).&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If you cannot upgrade yet, consider applying the changes from PR [#4096](https://github.com/py-pdf/pypdf/pull/4096).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-4160</guid>
      <pubDate>Thu, 01 Oct 2026 16:44:33 +0000</pubDate>
    </item>
  </channel>
</rss>
