<?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>Sat, 03 Oct 2026 19:09:32 +0000</lastBuildDate>
    <item>
      <title>bdu:2023-04049</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2023-04049</link>
      <description>bdu:2023-04049</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2023-04049</guid>
    </item>
    <item>
      <title>EUVD-2026-209809</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-209809</link>
      <description>EUVD-2026-209809</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-209809</guid>
    </item>
    <item>
      <title>fkie_cve-2023-22647</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-22647</link>
      <description>&lt;p&gt;An Improper Privilege Management vulnerability in SUSE Rancher allowed standard users to leverage their existing permissions to manipulate Kubernetes secrets in the local
 cluster, resulting in the secret being deleted, but their read-level 
permissions to the secret being preserved. When this operation was 
followed-up by other specially crafted commands, it could result in the 
user gaining access to tokens belonging to service accounts in the local cluster.&lt;/p&gt;
&lt;p&gt;This issue affects Rancher: from &amp;gt;= 2.6.0 before &amp;lt; 2.6.13, from &amp;gt;= 2.7.0 before &amp;lt; 2.7.4.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;An Improper Privilege Management vulnerability in SUSE Rancher allowed standard users to leverage their existing permissions to manipulate Kubernetes secrets in the local
 cluster, resulting in the secret being deleted, but their read-level 
permissions to the secret being preserved. When this operation was 
followed-up by other specially crafted commands, it could result in the 
user gaining access to tokens belonging to service accounts in the local cluster.&lt;/p&gt;
&lt;p&gt;This issue affects Rancher: from &amp;gt;= 2.6.0 before &amp;lt; 2.6.13, from &amp;gt;= 2.7.0 before &amp;lt; 2.7.4.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-22647</guid>
    </item>
    <item>
      <title>GHSA-p976-h52c-26p6 — Rancher vulnerable to Privilege Escalation via manipulation of Secrets</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-p976-h52c-26p6</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/rancher/rancher&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A vulnerability has been identified which enables [Standard users](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions) or above to elevate their permissions to Administrator in the `local` cluster.&lt;/p&gt;
&lt;p&gt;The `local` cluster means the cluster where Rancher is installed. It is named `local` inside the list of clusters in the Rancher UI.&lt;/p&gt;
&lt;p&gt;Standard users could leverage their existing permissions to manipulate Kubernetes secrets in the `local` cluster, resulting in the secret being deleted, but their read-level permissions to the secret being preserved. When this operation was followed-up by other specially crafted commands, it could result in the user gaining access to tokens belonging to service accounts in the `local` cluster.&lt;/p&gt;
&lt;p&gt;Users that have custom global roles which grant `create` and `delete` permissions on `secrets` would also be able to exploit this vulnerability.&lt;/p&gt;
&lt;p&gt;Users with [audit logs enabled](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log#enabling-api-audit-log) in Rancher can try to identify possible abuses of this issue by going through the logs. To sieve through the data filter by `kind: Secret` with `type: provisioning.cattle.io/cloud-credential`, then investigate all log entries that affect that specific resource. A secondary check would be to filter by all operations with `Opaque`…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/rancher/rancher&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;A vulnerability has been identified which enables [Standard users](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions) or above to elevate their permissions to Administrator in the `local` cluster.&lt;/p&gt;
&lt;p&gt;The `local` cluster means the cluster where Rancher is installed. It is named `local` inside the list of clusters in the Rancher UI.&lt;/p&gt;
&lt;p&gt;Standard users could leverage their existing permissions to manipulate Kubernetes secrets in the `local` cluster, resulting in the secret being deleted, but their read-level permissions to the secret being preserved. When this operation was followed-up by other specially crafted commands, it could result in the user gaining access to tokens belonging to service accounts in the `local` cluster.&lt;/p&gt;
&lt;p&gt;Users that have custom global roles which grant `create` and `delete` permissions on `secrets` would also be able to exploit this vulnerability.&lt;/p&gt;
&lt;p&gt;Users with [audit logs enabled](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log#enabling-api-audit-log) in Rancher can try to identify possible abuses of this issue by going through the logs. To sieve through the data filter by `kind: Secret` with `type: provisioning.cattle.io/cloud-credential`, then investigate all log entries that affect that specific resource. A secondary check would be to filter by all operations with `Opaque`…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-p976-h52c-26p6</guid>
    </item>
    <item>
      <title>gsd-2023-22647</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-22647</link>
      <description>gsd-2023-22647</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-22647</guid>
    </item>
    <item>
      <title>WID-SEC-W-2023-1340 — Rancher: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1340</link>
      <description>&lt;p&gt;Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in Rancher ausnutzen, um seine Privilegien zu erhöhen, Sicherheitsvorkehrungen zu umgehen oder einen Cross Site Scripting angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in Rancher ausnutzen, um seine Privilegien zu erhöhen, Sicherheitsvorkehrungen zu umgehen oder einen Cross Site Scripting angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1340</guid>
    </item>
  </channel>
</rss>
