Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Apache Polaris can issue broad temporary ("vended") storage credentials during staged table creation before the effective table location has been validated or durably reserved. Those temporary credentials are meant to limit the scope of accessible table data and metadata, but this scope limitation becomes attacker-directed because the attacker can choose a reachable target location. In the confirmed variant, if the caller supplies a custom location during stage create and requests credential vending, Apache Polaris uses that location to construct delegated storage credentials immediately. The stage-create path itself neither runs the normal location validation nor the overlap checks before those credentials are issued. Closely related to that, the staged-create flow also accepts write.data.path / write.metadata.path in the request properties and feeds those location overrides into the same effective table location set used for credential vending. Those fields are secondary to the…
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Iceberg, the table's metadata files are control files: they tell readers which data files belong to the table and which table version to read. 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. 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. 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. In that…
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.