<?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>Wed, 07 Oct 2026 00:00:23 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-232228</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-232228</link>
      <description>EUVD-2026-232228</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-232228</guid>
    </item>
    <item>
      <title>fkie_cve-2025-30095</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-30095</link>
      <description>&lt;p&gt;VyOS 1.3 through 1.5 (fixed in 1.4.2) or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon. I n VyOS, this is not the default configuration for the system SSH daemon, but is for the console service. To mitigate this, one can run &amp;#34;rm -f /etc/dropbear/*key*&amp;#34; and/or &amp;#34;rm -f /etc/dropbear-initramfs/*key*&amp;#34; and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;VyOS 1.3 through 1.5 (fixed in 1.4.2) or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon. I n VyOS, this is not the default configuration for the system SSH daemon, but is for the console service. To mitigate this, one can run &amp;#34;rm -f /etc/dropbear/*key*&amp;#34; and/or &amp;#34;rm -f /etc/dropbear-initramfs/*key*&amp;#34; and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-30095</guid>
    </item>
    <item>
      <title>GHSA-8vh6-m67f-4h33</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8vh6-m67f-4h33</link>
      <description>&lt;p&gt;VyOS 1.3 through 1.5 or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon. I n VyOS, this is not the default configuration for the system SSH daemon, but is for the console service. To mitigate this, one can run &amp;#34;rm -f /etc/dropbear/*key*&amp;#34; and/or &amp;#34;rm -f /etc/dropbear-initramfs/*key*&amp;#34; and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;VyOS 1.3 through 1.5 or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon. I n VyOS, this is not the default configuration for the system SSH daemon, but is for the console service. To mitigate this, one can run &amp;#34;rm -f /etc/dropbear/*key*&amp;#34; and/or &amp;#34;rm -f /etc/dropbear-initramfs/*key*&amp;#34; and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8vh6-m67f-4h33</guid>
    </item>
  </channel>
</rss>
