<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-06T19:32:14.312658+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2026-48510</id>
    <title>CVE-2026-48510 — MessagePack-CSharp: LZ4 decompression allocates from unbounded declared output lengths</title>
    <updated>2026-10-06T19:32:14.341611+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> MessagePack-CSharp</p>
<p>MessagePack for C# is a MessagePack serializer for C#. Prior to 2.5.301 and 3.1.7, when MessagePack-CSharp decompresses Lz4Block or Lz4BlockArray payloads, it reads declared uncompressed lengths from the wire and allocates output buffers based on those lengths before validating that the compressed data is valid or that the declared expansion is reasonable. A small payload can claim a very large uncompressed length and force a large allocation before LZ4 decoding begins. This vulnerability is fixed in 2.5.301 and 3.1.7.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-48510"/>
  </entry>
</feed>
