CVE-2026-42812
Awaiting Analysis Awaiting Analysis - Queue
Path Traversal in Apache Polaris

Publication date: 2026-05-04

Last updated on: 2026-05-04

Assigner: Apache Software Foundation

Description
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 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. 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 it. In plain terms, Polaris can later hand out temporary storage access for the same attacker-chosen area. That attacker-chosen area does not need to be limited to the poisoned table's own files. If it is a broader storage prefix, another table's prefix, or, depending on configuration or provider behavior, even a bucket/container root, the resulting disclosure or corruption scope can extend to any data and metadata Polaris can reach there. The practical consequences are therefore similar to the staged-create credential-vending issue already discussed: data and metadata reachable in that storage scope can be exposed and, if write-capable credentials are later issued, modified, corrupted, or removed. Even before that later credential step, Polaris itself performs the metadata write to the unchecked location. So the core issue is not only later credential vending. The primary defect is that Polaris skips its intended location checks before performing a security- sensitive metadata write when only `write.metadata.path` changes. When `polaris.config.allow.unstructured.table.location=false`, current code review suggests the later `updateTableLike(...)` validation usually rejects out-of-tree metadata locations before the unsafe path is persisted. That may reduce the persisted / credential-vending variant, but it does not prevent the underlying defect: Polaris still skips the intended pre-write location check when only `write.metadata.path` changes.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-04
Last Modified
2026-05-04
Generated
2026-05-07
AI Q&A
2026-05-05
EPSS Evaluated
2026-05-05
NVD
CVE-2026-42812
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
apache polaris *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-284 The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
CWE-732 The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
CWE-863 The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
CWE-20 The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that the configuration flag `polaris.config.allow.unstructured.table.location` is set to false to prevent unstructured table locations from being allowed.

Additionally, restrict the `allowedLocations` setting to a narrow, well-defined set of storage paths to prevent attacker-chosen locations from being accepted.

Avoid allowing users to change the `write.metadata.path` property through ALTER TABLE-style settings changes without proper validation.


Can you explain this vulnerability to me?

This vulnerability exists in Apache Iceberg's integration with Polaris, where the table's metadata files control which data files belong to a table and which table version to read.

The issue arises when changing the optional table property `write.metadata.path` through an ALTER TABLE-style settings change. This change bypasses the commit-time validation branch that is supposed to revalidate storage locations.

If the affected catalog is configured with `polaris.config.allow.unstructured.table.location=true` and has a broad enough `allowedLocations` allowlist, an attacker who can change table settings can cause Polaris to write new table metadata to an attacker-chosen storage location before validation occurs.

This can lead to Polaris persisting metadata paths to attacker-controlled locations and later handing out temporary cloud-storage credentials for those locations without revalidating them.

The attacker-chosen storage location can be broad, potentially affecting other tables or even entire storage buckets, leading to exposure, modification, corruption, or removal of data and metadata.

The core defect is that Polaris skips intended location checks before performing security-sensitive metadata writes when only `write.metadata.path` changes.


How can this vulnerability impact me? :

This vulnerability can have severe impacts including unauthorized exposure, modification, corruption, or removal of data and metadata stored in cloud storage locations accessible by Polaris.

An attacker with permission to change table settings can cause Polaris to write metadata to attacker-controlled storage locations and potentially receive temporary credentials granting access to those locations.

If the attacker-chosen location is broad, such as a storage bucket root or another table's prefix, the scope of data compromise can be extensive.

This can lead to data breaches, data integrity issues, and loss of availability for affected data.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart