<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-11T20:01:38.611189+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/rustsec-2026-0491</id>
    <title>RUSTSEC-2026-0491 — Memory amplification from record counts in the DNS message header</title>
    <updated>2026-11-11T20:01:38.613128+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: hickory-proto</p>
<p>When a DNS message is decoded, the vectors for the question, answer, authority and additional sections were created with `Vec::with_capacity` set to the counts in the message header. Those counts come from the sender and are not checked against the size of the message, so a single small packet that claims 65,535 records makes the decoder reserve memory for that many records (about 18 MB, according to the upstream advisory) before it reads any record and fails.</p>
<p>Any code that decodes untrusted DNS messages is exposed. That includes servers, and clients and resolvers that receive spoofed responses. Repeated packets can drive memory use up and cause a denial of service.</p>
<p>The fix caps the initial capacity at 8 entries and lets the vectors grow as records are actually decoded. It is in 0.26.2.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/rustsec-2026-0491"/>
  </entry>
</feed>
