<?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-03T16:32:24.589425+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/euvd-2026-43670</id>
    <title>EUVD-2026-43670</title>
    <updated>2026-10-03T16:32:24.702469+00:00</updated>
    <content>EUVD-2026-43670</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-43670"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2020-17467</id>
    <title>fkie_cve-2020-17467</title>
    <updated>2026-10-03T16:32:24.702509+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>An issue was discovered in FNET through 4.6.4. The code for processing the hostname from an LLMNR request doesn't check for '\0' termination. Therefore, the deduced length of the hostname doesn't reflect the correct length of the actual data. This may lead to Information Disclosure in _fnet_llmnr_poll in fnet_llmnr.c during a response to a malicious request of the DNS class IN.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2020-17467"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-wvw6-x7x2-94g8</id>
    <title>GHSA-wvw6-x7x2-94g8</title>
    <updated>2026-10-03T16:32:24.702545+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>An issue was discovered in FNET through 4.6.4. The code for processing the hostname from an LLMNR request doesn't check for '\0' termination. Therefore, the deduced length of the hostname doesn't reflect the correct length of the actual data. This may lead to Information Disclosure in _fnet_llmnr_poll in fnet_llmnr.c during a response to a malicious request of the DNS class IN.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-wvw6-x7x2-94g8"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/gsd-2020-17467</id>
    <title>gsd-2020-17467</title>
    <updated>2026-10-03T16:32:24.702564+00:00</updated>
    <content>gsd-2020-17467</content>
    <link href="https://cve.radiocsirt.org/vuln/gsd-2020-17467"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/icsa-20-343-01</id>
    <title>ICSA-20-343-01 — Multiple Embedded TCP/IP Stacks</title>
    <updated>2026-10-03T16:32:24.702577+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>The function used in uIP-Contiki-OS to process IPv6 extension headers and extension header options can be forced into an infinite loop state due to unchecked header/option lengths.CVE-2020-13984 has been assigned to this vulnerability. A CVSS v3 base score of 7.5 has been calculated; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The function used in uIP-Contiki-OS to decapsulate RPL extension headers does not check for unsafe integer conversion when parsing the values provided in a header, allowing an attacker to corrupt memory.CVE-2020-13985 has been assigned to this vulnerability. A CVSS v3 base score of 7.5 has been calculated; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The function used in uIP-Contiki-OS to decapsulate RPL extension headers does not check the length value of an RPL extension header received, allowing an attacker to cause it to enter an infinite loop.CVE-2020-13986 has been assigned to this vulnerability. A CVSS v3 base score of 7.5 has been calculated; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The function in open-iscsi, uIP-Contiki-OS, and uIP that parses incoming transport layer packets (TCP/UDP) does not check the length fields of packet headers against the data available in the packets. Given arbitrary lengths, an out-of-bounds memory read may be performed during the checksum computation.CVE-2020-13987 has been assigned to this vulnerability. A CVSS v3 base score of 8.2 has been calculat…</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/icsa-20-343-01"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2022-1044</id>
    <title>WID-SEC-W-2022-1044 — TCP/IP Stack: Mehrere Schwachstellen</title>
    <updated>2026-10-03T16:32:24.702680+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in TCP/IP Stack ausnutzen, um beliebigen Programmcode mit Administratorrechten auszuführen, einen Denial of Service Angriff durchzuführen, vertrauliche Daten einzusehen oder Daten zu manipulieren.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2022-1044"/>
  </entry>
</feed>
