<?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>Mon, 05 Oct 2026 03:46:50 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-7195 — Operator-sdk: privilege escalation due to incorrect permissions of /etc/passwd</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-7195</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; operator-framework operator-sdk, Red Hat RHEL-9-CNV-4.17, Red Hat RHEL-9-CNV-4.18, Red Hat RHEL-9-CNV-4.20, Red Hat multicluster engine for Kubernetes 2.6, Red Hat multicluster engine for Kubernetes 2.7, Red Hat multicluster engine for Kubernetes 2.8, Red Hat multicluster engine for Kubernetes 2.9, Red Hat OpenShift Compliance Operator 1, Red Hat OpenShift File Integrity Operator - FIO 1 and 19 more&lt;/p&gt;
&lt;p&gt;Early versions of Operator-SDK provided an insecure method to allow operator containers to run in environments that used a random UID. Operator-SDK before 0.15.2 provided a script, user_setup, which modifies the permissions of the /etc/passwd file to 664 during build time. Developers who used Operator-SDK before 0.15.2 to scaffold their operator may still be impacted by this if the insecure user_setup script is still being used to build new container images.&lt;/p&gt;
&lt;p&gt;In affected images, the /etc/passwd file is created during build time with group-writable permissions and a group ownership of root (gid=0). An attacker who can execute commands within an affected container, even as a non-root user, may be able to leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; operator-framework operator-sdk, Red Hat RHEL-9-CNV-4.17, Red Hat RHEL-9-CNV-4.18, Red Hat RHEL-9-CNV-4.20, Red Hat multicluster engine for Kubernetes 2.6, Red Hat multicluster engine for Kubernetes 2.7, Red Hat multicluster engine for Kubernetes 2.8, Red Hat multicluster engine for Kubernetes 2.9, Red Hat OpenShift Compliance Operator 1, Red Hat OpenShift File Integrity Operator - FIO 1 and 19 more&lt;/p&gt;
&lt;p&gt;Early versions of Operator-SDK provided an insecure method to allow operator containers to run in environments that used a random UID. Operator-SDK before 0.15.2 provided a script, user_setup, which modifies the permissions of the /etc/passwd file to 664 during build time. Developers who used Operator-SDK before 0.15.2 to scaffold their operator may still be impacted by this if the insecure user_setup script is still being used to build new container images.&lt;/p&gt;
&lt;p&gt;In affected images, the /etc/passwd file is created during build time with group-writable permissions and a group ownership of root (gid=0). An attacker who can execute commands within an affected container, even as a non-root user, may be able to leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-7195</guid>
    </item>
  </channel>
</rss>
