<?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>Tue, 06 Oct 2026 00:56:02 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-337233</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-337233</link>
      <description>EUVD-2026-337233</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-337233</guid>
    </item>
    <item>
      <title>fkie_cve-2026-44477</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-44477</link>
      <description>&lt;p&gt;CloudNativePG is a platform designed to manage PostgreSQL databases within Kubernetes environments. Prior to 1.29.1 and 1.28.3, the CloudNativePG metrics exporter opens its PostgreSQL connection as the postgres superuser via the pod-local Unix socket, then demotes the session with SET ROLE pg_monitor. SET ROLE changes only current_user; session_user remains postgres. Any SQL expression evaluated inside the scrape session can invoke RESET ROLE to recover real superuser privileges, then use COPY ... TO PROGRAM to spawn an OS-level subprocess as the postgres user inside the primary pod. The READ ONLY transaction flag does not block this; it gates writes to database state, not external processes. This vulnerability is fixed in 1.29.1 and 1.28.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;CloudNativePG is a platform designed to manage PostgreSQL databases within Kubernetes environments. Prior to 1.29.1 and 1.28.3, the CloudNativePG metrics exporter opens its PostgreSQL connection as the postgres superuser via the pod-local Unix socket, then demotes the session with SET ROLE pg_monitor. SET ROLE changes only current_user; session_user remains postgres. Any SQL expression evaluated inside the scrape session can invoke RESET ROLE to recover real superuser privileges, then use COPY ... TO PROGRAM to spawn an OS-level subprocess as the postgres user inside the primary pod. The READ ONLY transaction flag does not block this; it gates writes to database state, not external processes. This vulnerability is fixed in 1.29.1 and 1.28.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-44477</guid>
    </item>
    <item>
      <title>GHSA-423p-g724-fr39 — CloudNativePG's metrics exporter allows privilege escalation to PostgreSQL superuser and OS RCE</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-423p-g724-fr39</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/cloudnative-pg/cloudnative-pg&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The CloudNativePG metrics exporter opens its PostgreSQL connection as the `postgres` superuser via the pod-local Unix socket, then demotes the session with `SET ROLE pg_monitor`. `SET ROLE` changes only `current_user`; `session_user` remains `postgres`. That residual superuser identity is the foothold for the rest of the chain.&lt;/p&gt;
&lt;p&gt;Any SQL expression evaluated inside the scrape session can invoke `RESET ROLE` to recover real superuser privileges, then use `COPY ... TO PROGRAM` to spawn an OS-level subprocess as the `postgres` user inside the primary pod. The `READ ONLY` transaction flag does not block this; it gates writes to database state, not external processes.&lt;/p&gt;
&lt;p&gt;Two exploitation paths follow from this root cause.&lt;/p&gt;
&lt;p&gt;#### Path 1: custom metric queries with unqualified identifiers (all supported releases)&lt;/p&gt;
&lt;p&gt;A database user who owns a schema on the `search_path` of any scraped database can plant a shadow object whose name matches an unqualified identifier in a custom metric query. When the exporter next evaluates that query, the shadow expression executes inside the `session_user = postgres` scrape session, giving the attacker PostgreSQL superuser privileges and OS command execution inside the primary pod within one scrape interval (≤30 s). Exploitability requires a custom metric query that contains an unqualified relation or function reference.&lt;/p&gt;
&lt;p&gt;Although `search_path` shadowing of unqualified identifiers is the most direct case, the underlying bug is that any express…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/cloudnative-pg/cloudnative-pg&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;The CloudNativePG metrics exporter opens its PostgreSQL connection as the `postgres` superuser via the pod-local Unix socket, then demotes the session with `SET ROLE pg_monitor`. `SET ROLE` changes only `current_user`; `session_user` remains `postgres`. That residual superuser identity is the foothold for the rest of the chain.&lt;/p&gt;
&lt;p&gt;Any SQL expression evaluated inside the scrape session can invoke `RESET ROLE` to recover real superuser privileges, then use `COPY ... TO PROGRAM` to spawn an OS-level subprocess as the `postgres` user inside the primary pod. The `READ ONLY` transaction flag does not block this; it gates writes to database state, not external processes.&lt;/p&gt;
&lt;p&gt;Two exploitation paths follow from this root cause.&lt;/p&gt;
&lt;p&gt;#### Path 1: custom metric queries with unqualified identifiers (all supported releases)&lt;/p&gt;
&lt;p&gt;A database user who owns a schema on the `search_path` of any scraped database can plant a shadow object whose name matches an unqualified identifier in a custom metric query. When the exporter next evaluates that query, the shadow expression executes inside the `session_user = postgres` scrape session, giving the attacker PostgreSQL superuser privileges and OS command execution inside the primary pod within one scrape interval (≤30 s). Exploitability requires a custom metric query that contains an unqualified relation or function reference.&lt;/p&gt;
&lt;p&gt;Although `search_path` shadowing of unqualified identifiers is the most direct case, the underlying bug is that any express…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-423p-g724-fr39</guid>
    </item>
  </channel>
</rss>
