<?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>Thu, 08 Oct 2026 04:51:13 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-05574</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-05574</link>
      <description>bdu:2024-05574</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-05574</guid>
    </item>
    <item>
      <title>EUVD-2026-5045</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-5045</link>
      <description>EUVD-2026-5045</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-5045</guid>
    </item>
    <item>
      <title>fkie_cve-2024-31989</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-31989</link>
      <description>&lt;p&gt;Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It has been discovered that an unprivileged pod in a different namespace on the same cluster could connect to the Redis server on port 6379. Despite having installed the latest version of the VPC CNI plugin on the EKS cluster, it requires manual enablement through configuration to enforce network policies. This raises concerns that many clients might unknowingly have open access to their Redis servers. This vulnerability could lead to Privilege Escalation to the level of cluster controller, or to information leakage, affecting anyone who does not have strict access controls on their Redis instance. This issue has been patched in version(s) 2.8.19, 2.9.15 and 2.10.10.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It has been discovered that an unprivileged pod in a different namespace on the same cluster could connect to the Redis server on port 6379. Despite having installed the latest version of the VPC CNI plugin on the EKS cluster, it requires manual enablement through configuration to enforce network policies. This raises concerns that many clients might unknowingly have open access to their Redis servers. This vulnerability could lead to Privilege Escalation to the level of cluster controller, or to information leakage, affecting anyone who does not have strict access controls on their Redis instance. This issue has been patched in version(s) 2.8.19, 2.9.15 and 2.10.10.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-31989</guid>
    </item>
    <item>
      <title>GHSA-9766-5277-j5hr — ArgoCD Vulnerable to Use of Risky or Missing Cryptographic Algorithms in Redis Cache</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9766-5277-j5hr</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/argoproj/argo-cd/v2, Go: github.com/argoproj/argo-cd&lt;/p&gt;
&lt;p&gt;### Summary
By default, the Redis database server is not password-protected. Consequently, an attacker with access to the Redis server can gain read/write access to the data in Redis. The attacker can also modify the &amp;#34;mfst&amp;#34; (manifest) key to cause ArgoCD to execute any deployment, potentially leveraging ArgoCD&amp;#39;s high privileges to take over the cluster. Updating the &amp;#34;cacheEntryHash&amp;#34; in the manifest JSON is necessary, but since it doesn&amp;#39;t use a private key for signing its integrity, a simple script can generate a new FNV64a hash matching the new manifest values. The repo-server, unable to verify if its cache is compromised, will read the altered &amp;#34;mfst&amp;#34; key and initiate an update process for the injected deployment.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s also possible to edit the &amp;#34;app|resources-tree&amp;#34; key, causing the ArgoCD server to load any Kubernetes resource into the live manifest section of the app preview. This could lead to an information leak.&lt;/p&gt;
&lt;p&gt;The fact that the cache in Redis is neither signed nor validated, combined with Redis&amp;#39;s default lack of password protection, presents a significant security concern given ArgoCD&amp;#39;s high-level permissions within the cluster. A security update should ensure all Redis database values are signed or encrypted.&lt;/p&gt;
&lt;p&gt;### Details
We began by deploying ArgoCD on an EKS cluster. Surprisingly, we discovered that an unprivileged pod in a different namespace on the same cluster could connect to the Redis server on port 6379. This was unexpected, as we had observed network polic…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/argoproj/argo-cd/v2, Go: github.com/argoproj/argo-cd&lt;/p&gt;
&lt;p&gt;### Summary
By default, the Redis database server is not password-protected. Consequently, an attacker with access to the Redis server can gain read/write access to the data in Redis. The attacker can also modify the &amp;#34;mfst&amp;#34; (manifest) key to cause ArgoCD to execute any deployment, potentially leveraging ArgoCD&amp;#39;s high privileges to take over the cluster. Updating the &amp;#34;cacheEntryHash&amp;#34; in the manifest JSON is necessary, but since it doesn&amp;#39;t use a private key for signing its integrity, a simple script can generate a new FNV64a hash matching the new manifest values. The repo-server, unable to verify if its cache is compromised, will read the altered &amp;#34;mfst&amp;#34; key and initiate an update process for the injected deployment.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s also possible to edit the &amp;#34;app|resources-tree&amp;#34; key, causing the ArgoCD server to load any Kubernetes resource into the live manifest section of the app preview. This could lead to an information leak.&lt;/p&gt;
&lt;p&gt;The fact that the cache in Redis is neither signed nor validated, combined with Redis&amp;#39;s default lack of password protection, presents a significant security concern given ArgoCD&amp;#39;s high-level permissions within the cluster. A security update should ensure all Redis database values are signed or encrypted.&lt;/p&gt;
&lt;p&gt;### Details
We began by deploying ArgoCD on an EKS cluster. Surprisingly, we discovered that an unprivileged pod in a different namespace on the same cluster could connect to the Redis server on port 6379. This was unexpected, as we had observed network polic…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9766-5277-j5hr</guid>
    </item>
    <item>
      <title>gsd-2024-31989</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2024-31989</link>
      <description>gsd-2024-31989</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2024-31989</guid>
    </item>
    <item>
      <title>RHSA-2024:3368 — Red Hat Security Advisory: Errata Advisory for Red Hat OpenShift GitOps v1.12.3 security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:3368</link>
      <description>&lt;p&gt;argocd: Use of Risky or Missing Cryptographic Algorithms in Redis Cache&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;argocd: Use of Risky or Missing Cryptographic Algorithms in Redis Cache&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:3368</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1239 — Red Hat OpenShift GitOps: Schwachstelle ermöglicht Privilegieneskalation</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1239</link>
      <description>&lt;p&gt;Ein Angreifer aus einem unprivilegierten Pod auf demselben Cluster kann eine Schwachstelle in Red Hat OpenShift GitOps ausnutzen, um seine Privilegien zu erhöhen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer aus einem unprivilegierten Pod auf demselben Cluster kann eine Schwachstelle in Red Hat OpenShift GitOps ausnutzen, um seine Privilegien zu erhöhen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1239</guid>
    </item>
  </channel>
</rss>
