<?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-08T08:46:37.965839+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/bdu:2024-05574</id>
    <title>bdu:2024-05574</title>
    <updated>2026-10-08T08:46:38.091454+00:00</updated>
    <content>bdu:2024-05574</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2024-05574"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-5045</id>
    <title>EUVD-2026-5045</title>
    <updated>2026-10-08T08:46:38.091500+00:00</updated>
    <content>EUVD-2026-5045</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-5045"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2024-31989</id>
    <title>fkie_cve-2024-31989</title>
    <updated>2026-10-08T08:46:38.091514+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2024-31989"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-9766-5277-j5hr</id>
    <title>GHSA-9766-5277-j5hr — ArgoCD Vulnerable to Use of Risky or Missing Cryptographic Algorithms in Redis Cache</title>
    <updated>2026-10-08T08:46:38.091549+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/argoproj/argo-cd/v2, Go: github.com/argoproj/argo-cd</p>
<p>### 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 "mfst" (manifest) key to cause ArgoCD to execute any deployment, potentially leveraging ArgoCD's high privileges to take over the cluster. Updating the "cacheEntryHash" in the manifest JSON is necessary, but since it doesn'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 "mfst" key and initiate an update process for the injected deployment.</p>
<p>It's also possible to edit the "app|resources-tree" 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.</p>
<p>The fact that the cache in Redis is neither signed nor validated, combined with Redis's default lack of password protection, presents a significant security concern given ArgoCD's high-level permissions within the cluster. A security update should ensure all Redis database values are signed or encrypted.</p>
<p>### 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…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-9766-5277-j5hr"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/gsd-2024-31989</id>
    <title>gsd-2024-31989</title>
    <updated>2026-10-08T08:46:38.091615+00:00</updated>
    <content>gsd-2024-31989</content>
    <link href="https://cve.radiocsirt.org/vuln/gsd-2024-31989"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/rhsa-2024:3368</id>
    <title>RHSA-2024:3368 — Red Hat Security Advisory: Errata Advisory for Red Hat OpenShift GitOps v1.12.3 security update</title>
    <updated>2026-10-08T08:46:38.091629+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>argocd: Use of Risky or Missing Cryptographic Algorithms in Redis Cache</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/rhsa-2024:3368"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1239</id>
    <title>WID-SEC-W-2024-1239 — Red Hat OpenShift GitOps: Schwachstelle ermöglicht Privilegieneskalation</title>
    <updated>2026-10-08T08:46:38.091655+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer aus einem unprivilegierten Pod auf demselben Cluster kann eine Schwachstelle in Red Hat OpenShift GitOps ausnutzen, um seine Privilegien zu erhöhen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1239"/>
  </entry>
</feed>
