<?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://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>Sat, 03 Oct 2026 19:23:10 +0000</lastBuildDate>
    <item>
      <title>BREW-crytic-compile-CVE-2025-68131 — CBORDecoder reuse can leak shareable values across decode calls</title>
      <link>https://cve.radiocsirt.org/vuln/brew-crytic-compile-cve-2025-68131</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: crytic-compile&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; Homebrew: crytic-compile&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://cve.radiocsirt.org/vuln/brew-crytic-compile-cve-2025-68131</guid>
    </item>
    <item>
      <title>EUVD-2026-264757</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-264757</link>
      <description>EUVD-2026-264757</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-264757</guid>
    </item>
    <item>
      <title>fkie_cve-2025-68131</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-68131</link>
      <description>&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;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://cve.radiocsirt.org/vuln/fkie_cve-2025-68131</guid>
    </item>
    <item>
      <title>GHSA-wcj4-jw5j-44wh — CBORDecoder reuse can leak shareable values across decode calls</title>
      <link>https://cve.radiocsirt.org/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://cve.radiocsirt.org/vuln/ghsa-wcj4-jw5j-44wh</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:10014-1 — python311-cbor2-5.8.0-2.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:10014-1</link>
      <description>&lt;p&gt;python311-cbor2-5.8.0-2.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;python311-cbor2-5.8.0-2.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:10014-1</guid>
    </item>
    <item>
      <title>PYSEC-2025-90</title>
      <link>https://cve.radiocsirt.org/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://cve.radiocsirt.org/vuln/pysec-2025-90</guid>
    </item>
    <item>
      <title>RHSA-2026:10184 — Red Hat Security Advisory: RHOAI 2.25.5 - Red Hat OpenShift AI</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:10184</link>
      <description>&lt;p&gt;vllm: Server Side request forgery (SSRF) in MediaConnector feast: Feast: Remote Code Execution via insecure YAML deserialization openshift-ai: Trusty AI Grants All Authenticated users to list pods in any namespace nltk: Zip Slip Vulnerability in nltk Leading to Code Execution golang: net/url: Memory exhaustion in query parameter parsing in net/url golang: archive/zip: Excessive CPU consumption when building archive index in archive/zip crypto/x509: golang: Denial of Service due to excessive resource consumption via crafted certificate urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion urllib3: urllib3 Streaming API improperly handles highly compressed data cbor2: cbor2: Information Disclosure via shared memory in CBORDecoder reuse aiohttp: AIOHTTP&amp;#39;s HTTP Parser auto_decompress feature is vulnerable to zip bomb aiohttp: aiohttp: Denial of Service via specially crafted POST request aiohttp: aiohttp: Denial of Service via memory exhaustion from crafted POST request python-markdown: denial of service via malformed HTML-like sequences nltk: NLTK: Arbitrary file read via improper path validation in `filestring()` function nltk: NLTK: Arbitrary file read via path traversal vulnerability io.vertx/vertx-core: static handler component cache can be manipulated to deny the access to static files google-cloud-aiplatform: google-cloud-aiplatform: Arbitrary code execution via Stored Cross-Site Scripting (XSS) tensorflow: TensorFlow: Local privilege escalation via…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;vllm: Server Side request forgery (SSRF) in MediaConnector feast: Feast: Remote Code Execution via insecure YAML deserialization openshift-ai: Trusty AI Grants All Authenticated users to list pods in any namespace nltk: Zip Slip Vulnerability in nltk Leading to Code Execution golang: net/url: Memory exhaustion in query parameter parsing in net/url golang: archive/zip: Excessive CPU consumption when building archive index in archive/zip crypto/x509: golang: Denial of Service due to excessive resource consumption via crafted certificate urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion urllib3: urllib3 Streaming API improperly handles highly compressed data cbor2: cbor2: Information Disclosure via shared memory in CBORDecoder reuse aiohttp: AIOHTTP&amp;#39;s HTTP Parser auto_decompress feature is vulnerable to zip bomb aiohttp: aiohttp: Denial of Service via specially crafted POST request aiohttp: aiohttp: Denial of Service via memory exhaustion from crafted POST request python-markdown: denial of service via malformed HTML-like sequences nltk: NLTK: Arbitrary file read via improper path validation in `filestring()` function nltk: NLTK: Arbitrary file read via path traversal vulnerability io.vertx/vertx-core: static handler component cache can be manipulated to deny the access to static files google-cloud-aiplatform: google-cloud-aiplatform: Arbitrary code execution via Stored Cross-Site Scripting (XSS) tensorflow: TensorFlow: Local privilege escalation via…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:10184</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:21139-1 — Security update for python-cbor2</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:21139-1</link>
      <description>&lt;p&gt;Security update for python-cbor2&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for python-cbor2&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:21139-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-68131</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68131</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: cbor2, Ubuntu:24.04:LTS: cbor2, Ubuntu:25.10: cbor2, Ubuntu:26.04:LTS: 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; Ubuntu:22.04:LTS: cbor2, Ubuntu:24.04:LTS: cbor2, Ubuntu:25.10: cbor2, Ubuntu:26.04:LTS: 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://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68131</guid>
    </item>
  </channel>
</rss>
