<?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-05T20:07:22.549320+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-2024-21653</id>
    <title>CVE-2024-21653 — vantage6 insecure SSH configuration for node and server containers</title>
    <updated>2026-10-05T20:07:22.580982+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> vantage6</p>
<p>The vantage6 technology enables to manage and deploy privacy enhancing technologies like Federated Learning (FL) and Multi-Party Computation (MPC).  Nodes and servers get a ssh config by default that permits root login with password authentication. In a proper deployment, the SSH service is not exposed so there is no risk, but not all deployments are ideal. The default should therefore be less permissive.  The vulnerability can be mitigated by removing the ssh part from the docker file and rebuilding the docker image.  Version 4.2.0 patches the vulnerability.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2024-21653"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-2wgc-48g2-cj5w</id>
    <title>GHSA-2wgc-48g2-cj5w — vantage6 has insecure SSH configuration for node and server containers</title>
    <updated>2026-10-05T20:07:22.581052+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: vantage6</p>
<p>### Impact
Nodes and servers get a ssh config by default that permits root login with password authentication. In a proper deployment, the SSH service is not exposed so there is no risk, but not all deployments are ideal. The default should therefore be less permissive.</p>
<p>We will probably opt to completely remove the ssh option as it is only used for debugging. Later, we can add a debug mode where we can activate it if necessary.</p>
<p>### Workarounds
Remove the ssh part from the docker file and build your own docker image</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-2wgc-48g2-cj5w"/>
  </entry>
</feed>
