CVE-2026-42812

*** Pendiente de traducción *** In Apache Iceberg, the table&amp;#39;s metadata files are control files: they tell readers<br /> which data files belong to the table and which table version to read.<br /> <br /> <br /> <br /> `write.metadata.path` is an optional table property that tells Polaris<br /> where to<br /> write those metadata files. <br /> For a table already registered in a<br /> Polaris-managed<br /> catalog, changing only that property through an `ALTER TABLE`-style settings<br /> change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses<br /> the commit-time branch that is supposed to revalidate storage locations.<br /> <br /> The full persisted / credential-vending variant requires the affected<br /> catalog<br /> to have `polaris.config.allow.unstructured.table.location=true`, with<br /> `allowedLocations` broad enough to include the attacker-chosen target.<br /> <br /> <br /> `allowedLocations` is the admin-configured allowlist of storage paths that<br /> the<br /> catalog is allowed to use. Public project materials suggest that this flag<br /> is a<br /> real supported compatibility / layout mode, not just a contrived lab-only<br /> prerequisite.<br /> <br /> <br /> In that configuration, a user who can change table settings can cause Apache Polaris<br /> itself to write new table metadata to an attacker-chosen reachable storage<br /> location before the intended location-validation branch runs.<br /> <br /> If the later concrete-path validation also accepts that location, Polaris<br /> persists the resulting metadata path into stored table state. Later<br /> table-load<br /> and credential APIs can then return temporary cloud-storage credentials for<br /> the<br /> same location without revalidating it. In plain terms, Polaris can later<br /> hand<br /> out temporary storage access for the same attacker-chosen area.<br /> <br /> That attacker-chosen area does not need to be limited to the poisoned<br /> table&amp;#39;s<br /> own files. If it is a broader storage prefix, another table&amp;#39;s prefix, or,<br /> depending on configuration or provider behavior, even a bucket/container<br /> root,<br /> the resulting disclosure or corruption scope can extend to any data and<br /> metadata Polaris can reach there.<br /> <br /> <br /> <br /> The practical consequences are therefore similar to the staged-create<br /> credential-vending issue already discussed: data and metadata reachable in<br /> that<br /> storage scope can be exposed and, if write-capable credentials are later<br /> issued, modified, corrupted, or removed. Even before that later credential<br /> step, Polaris itself performs the metadata write to the unchecked location.<br /> <br /> So the core issue is not only later credential vending. <br /> <br /> The primary defect<br /> is<br /> that Polaris skips its intended location checks before performing a<br /> security-<br /> sensitive metadata write when only `write.metadata.path` changes.<br /> <br /> <br /> <br /> When `polaris.config.allow.unstructured.table.location=false`, current code<br /> review suggests the later `updateTableLike(...)` validation usually rejects<br /> out-of-tree metadata locations before the unsafe path is persisted. That may<br /> reduce the persisted / credential-vending variant, but it does not prevent<br /> the<br /> underlying defect: Polaris still skips the intended pre-write location check<br /> when only `write.metadata.path` changes.