<?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 04:53:57 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-308402</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-308402</link>
      <description>EUVD-2026-308402</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-308402</guid>
    </item>
    <item>
      <title>fkie_cve-2026-42812</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-42812</link>
      <description>&lt;p&gt;In Apache Iceberg, the table&amp;#39;s metadata files are control files: they tell readers
which data files belong to the table and which table version to read.&lt;/p&gt;
&lt;p&gt;`write.metadata.path` is an optional table property that tells Polaris
where to
write those metadata files. 
For a table already registered in a
Polaris-managed
catalog, changing only that property through an `ALTER TABLE`-style settings
change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses
the commit-time branch that is supposed to revalidate storage locations.&lt;/p&gt;
&lt;p&gt;The full persisted / credential-vending variant requires the affected
catalog
to have `polaris.config.allow.unstructured.table.location=true`, with
`allowedLocations` broad enough to include the attacker-chosen target.&lt;/p&gt;
&lt;p&gt;`allowedLocations` is the admin-configured allowlist of storage paths that
the
catalog is allowed to use. Public project materials suggest that this flag
is a
real supported compatibility / layout mode, not just a contrived lab-only
prerequisite.&lt;/p&gt;
&lt;p&gt;In that configuration, a user who can change table settings can cause Apache Polaris
itself to write new table metadata to an attacker-chosen reachable storage
location before the intended location-validation branch runs.&lt;/p&gt;
&lt;p&gt;If the later concrete-path validation also accepts that location, Polaris
persists the resulting metadata path into stored table state. Later
table-load
and credential APIs can then return temporary cloud-storage credentials for
the
same location without revalid…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In Apache Iceberg, the table&amp;#39;s metadata files are control files: they tell readers
which data files belong to the table and which table version to read.&lt;/p&gt;
&lt;p&gt;`write.metadata.path` is an optional table property that tells Polaris
where to
write those metadata files. 
For a table already registered in a
Polaris-managed
catalog, changing only that property through an `ALTER TABLE`-style settings
change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses
the commit-time branch that is supposed to revalidate storage locations.&lt;/p&gt;
&lt;p&gt;The full persisted / credential-vending variant requires the affected
catalog
to have `polaris.config.allow.unstructured.table.location=true`, with
`allowedLocations` broad enough to include the attacker-chosen target.&lt;/p&gt;
&lt;p&gt;`allowedLocations` is the admin-configured allowlist of storage paths that
the
catalog is allowed to use. Public project materials suggest that this flag
is a
real supported compatibility / layout mode, not just a contrived lab-only
prerequisite.&lt;/p&gt;
&lt;p&gt;In that configuration, a user who can change table settings can cause Apache Polaris
itself to write new table metadata to an attacker-chosen reachable storage
location before the intended location-validation branch runs.&lt;/p&gt;
&lt;p&gt;If the later concrete-path validation also accepts that location, Polaris
persists the resulting metadata path into stored table state. Later
table-load
and credential APIs can then return temporary cloud-storage credentials for
the
same location without revalid…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-42812</guid>
    </item>
    <item>
      <title>GHSA-w76p-3cgp-qfcm — Apache Polaris has an Improper Input Validation issue</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-w76p-3cgp-qfcm</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.apache.polaris:polaris-runtime-service&lt;/p&gt;
&lt;p&gt;In Apache Iceberg, the table&amp;#39;s metadata files are control files: they tell readers which data files belong to the table and which table version to read.&lt;/p&gt;
&lt;p&gt;`write.metadata.path` is an optional table property that tells Polaris where to write those metadata files. For a table already registered in a Polaris-managed catalog, changing only that property through an `ALTER TABLE`-style settings change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses the commit-time branch that is supposed to revalidate storage locations.&lt;/p&gt;
&lt;p&gt;The full persisted / credential-vending variant requires the affected catalog to have `polaris.config.allow.unstructured.table.location=true`, with `allowedLocations` broad enough to include the attacker-chosen target.&lt;/p&gt;
&lt;p&gt;`allowedLocations` is the admin-configured allowlist of storage paths that the catalog is allowed to use. Public project materials suggest that this flag is a real supported compatibility / layout mode, not just a contrived lab-only prerequisite.&lt;/p&gt;
&lt;p&gt;In that configuration, a user who can change table settings can cause Apache Polaris itself to write new table metadata to an attacker-chosen reachable storage location before the intended location-validation branch runs.&lt;/p&gt;
&lt;p&gt;If the later concrete-path validation also accepts that location, Polaris persists the resulting metadata path into stored table state. Later table-load and credential APIs can then return temporary cloud-storage credentials for the same location without revalidating…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.apache.polaris:polaris-runtime-service&lt;/p&gt;
&lt;p&gt;In Apache Iceberg, the table&amp;#39;s metadata files are control files: they tell readers which data files belong to the table and which table version to read.&lt;/p&gt;
&lt;p&gt;`write.metadata.path` is an optional table property that tells Polaris where to write those metadata files. For a table already registered in a Polaris-managed catalog, changing only that property through an `ALTER TABLE`-style settings change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses the commit-time branch that is supposed to revalidate storage locations.&lt;/p&gt;
&lt;p&gt;The full persisted / credential-vending variant requires the affected catalog to have `polaris.config.allow.unstructured.table.location=true`, with `allowedLocations` broad enough to include the attacker-chosen target.&lt;/p&gt;
&lt;p&gt;`allowedLocations` is the admin-configured allowlist of storage paths that the catalog is allowed to use. Public project materials suggest that this flag is a real supported compatibility / layout mode, not just a contrived lab-only prerequisite.&lt;/p&gt;
&lt;p&gt;In that configuration, a user who can change table settings can cause Apache Polaris itself to write new table metadata to an attacker-chosen reachable storage location before the intended location-validation branch runs.&lt;/p&gt;
&lt;p&gt;If the later concrete-path validation also accepts that location, Polaris persists the resulting metadata path into stored table state. Later table-load and credential APIs can then return temporary cloud-storage credentials for the same location without revalidating…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-w76p-3cgp-qfcm</guid>
    </item>
  </channel>
</rss>
