<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T03:13:25.739636+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2025-68131</id>
    <title>CVE-2025-68131 — CBORDecoder reuse can leak shareable values across decode calls</title>
    <updated>2026-09-30T03:13:26.670835+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> agronholm cbor2</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2025-68131"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-wcj4-jw5j-44wh</id>
    <title>GHSA-wcj4-jw5j-44wh — CBORDecoder reuse can leak shareable values across decode calls</title>
    <updated>2026-09-30T03:13:26.670962+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: cbor2</p>
<p>### 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.</p>
<p>### Details
The issue is in the decoder's handling of the shareables list, which stores values tagged with CBOR tag 28 (shareable) for later reference by tag 29 (sharedref).</p>
<p>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.</p>
<p>The issue exists in both the C extension and the pure Python decoder.</p>
<p>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:</p>
<p>```
  static int
  _CBORDecoder_set_fp(CBORDecoderObject *self, PyObject *value, void *closure)
  {
      // ... validation ...
      tmp = self-&gt;read;
      self-&gt;read = read;
      Py_DECREF(tmp);
      return 0;
      // Missing: PyList_Clear(self-&gt;shareables) or equivalent
  }
```</p>
<p>In the pure Python decoder (cbor2/_decoder.py), the fp setter similarly fails to clear self._shareables.</p>
<p>Similarly, decode_from_bytes() in both implementations saves and restores the read pointer but does not clear the shareables list between decodes.</p>
<p>The shareable/sharedr…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-wcj4-jw5j-44wh"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/pysec-2025-90</id>
    <title>PYSEC-2025-90</title>
    <updated>2026-09-30T03:13:26.671083+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: cbor2</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/pysec-2025-90"/>
  </entry>
</feed>
