<?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 all</title>
    <link>https://vulnerability.circl.lu</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>Tue, 29 Sep 2026 02:55:19 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-68131 — CBORDecoder reuse can leak shareable values across decode calls</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-68131</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; agronholm cbor2&lt;/p&gt;
&lt;p&gt;cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) serialization format. Starting in version 3.0.0 and prior to version 5.8.0, whhen a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries. Version 5.8.0 patches the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; agronholm cbor2&lt;/p&gt;
&lt;p&gt;cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) serialization format. Starting in version 3.0.0 and prior to version 5.8.0, whhen a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries. Version 5.8.0 patches the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-68131</guid>
    </item>
    <item>
      <title>GHSA-wcj4-jw5j-44wh — CBORDecoder reuse can leak shareable values across decode calls</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-wcj4-jw5j-44wh</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: cbor2&lt;/p&gt;
&lt;p&gt;### Summary
When a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries.&lt;/p&gt;
&lt;p&gt;### Details
The issue is in the decoder&amp;#39;s handling of the shareables list, which stores values tagged with CBOR tag 28 (shareable) for later reference by tag 29 (sharedref).&lt;/p&gt;
&lt;p&gt;When decode_from_bytes() is called or when .fp is set to a new stream, the shareables list is not cleared. This allows references to persist across separate decode operations.&lt;/p&gt;
&lt;p&gt;The issue exists in both the C extension and the pure Python decoder.&lt;/p&gt;
&lt;p&gt;In the C extension (source/decoder.c), the _CBORDecoder_set_fp function (line ~202) updates the file pointer but does not reset the shareables state:&lt;/p&gt;
&lt;p&gt;```
  static int
  _CBORDecoder_set_fp(CBORDecoderObject *self, PyObject *value, void *closure)
  {
      // ... validation ...
      tmp = self-&amp;gt;read;
      self-&amp;gt;read = read;
      Py_DECREF(tmp);
      return 0;
      // Missing: PyList_Clear(self-&amp;gt;shareables) or equivalent
  }
```&lt;/p&gt;
&lt;p&gt;In the pure Python decoder (cbor2/_decoder.py), the fp setter similarly fails to clear self._shareables.&lt;/p&gt;
&lt;p&gt;Similarly, decode_from_bytes() in both implementations saves and restores the read pointer but does not clear the shareables list between decodes.&lt;/p&gt;
&lt;p&gt;The shareable/sharedr…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: cbor2&lt;/p&gt;
&lt;p&gt;### Summary
When a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries.&lt;/p&gt;
&lt;p&gt;### Details
The issue is in the decoder&amp;#39;s handling of the shareables list, which stores values tagged with CBOR tag 28 (shareable) for later reference by tag 29 (sharedref).&lt;/p&gt;
&lt;p&gt;When decode_from_bytes() is called or when .fp is set to a new stream, the shareables list is not cleared. This allows references to persist across separate decode operations.&lt;/p&gt;
&lt;p&gt;The issue exists in both the C extension and the pure Python decoder.&lt;/p&gt;
&lt;p&gt;In the C extension (source/decoder.c), the _CBORDecoder_set_fp function (line ~202) updates the file pointer but does not reset the shareables state:&lt;/p&gt;
&lt;p&gt;```
  static int
  _CBORDecoder_set_fp(CBORDecoderObject *self, PyObject *value, void *closure)
  {
      // ... validation ...
      tmp = self-&amp;gt;read;
      self-&amp;gt;read = read;
      Py_DECREF(tmp);
      return 0;
      // Missing: PyList_Clear(self-&amp;gt;shareables) or equivalent
  }
```&lt;/p&gt;
&lt;p&gt;In the pure Python decoder (cbor2/_decoder.py), the fp setter similarly fails to clear self._shareables.&lt;/p&gt;
&lt;p&gt;Similarly, decode_from_bytes() in both implementations saves and restores the read pointer but does not clear the shareables list between decodes.&lt;/p&gt;
&lt;p&gt;The shareable/sharedr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-wcj4-jw5j-44wh</guid>
    </item>
    <item>
      <title>PYSEC-2025-90</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2025-90</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: cbor2&lt;/p&gt;
&lt;p&gt;cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) serialization format. Starting in version 3.0.0 and prior to version 5.8.0, whhen a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries. Version 5.8.0 patches the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: cbor2&lt;/p&gt;
&lt;p&gt;cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) serialization format. Starting in version 3.0.0 and prior to version 5.8.0, whhen a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries. Version 5.8.0 patches the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2025-90</guid>
    </item>
  </channel>
</rss>
