CVE-2026-42812: Apache Polaris Auth Bypass Vulnerability

CVE-2026-42812 Overview

CVE-2026-42812 affects Apache Iceberg and Apache Polaris, where the table property write.metadata.path bypasses location validation when modified through an ALTER TABLE-style settings change. A user with table modification privileges can redirect metadata writes to attacker-chosen storage locations. When the catalog runs with polaris.config.allow.unstructured.table.location=true and a sufficiently broad allowedLocations, Polaris persists the unchecked path and later vends temporary cloud-storage credentials for that area. The flaw maps to [CWE-20: Improper Input Validation] and carries a CVSS 4.0 score of 9.4.

Critical Impact

Authenticated catalog users can coerce Apache Polaris into writing table metadata to attacker-chosen storage and subsequently obtain credentials that read or modify data outside the original table's prefix.

Affected Products

• Apache Iceberg (table metadata layer)
• Apache Polaris (catalog service)
• Deployments with polaris.config.allow.unstructured.table.location=true and broad allowedLocations

Discovery Timeline

• 2026-05-04 - CVE-2026-42812 published to NVD
• 2026-05-05 - Last updated in NVD database

Technical Details for CVE-2026-42812

Vulnerability Analysis

Apache Iceberg metadata files act as control files that direct readers to the data files and table version they should consume. The write.metadata.path property tells Polaris where to persist those metadata files. Polaris validates storage locations on the commit-time branch that handles row-level operations such as INSERT, SELECT, UPDATE, and DELETE. Changing only write.metadata.path through a settings update bypasses that branch entirely.

The consequence is twofold. First, Polaris itself performs a security-sensitive metadata write to the unvalidated location before any later check executes. Second, when the deployment also enables unstructured table locations, the later updateTableLike(...) validation can accept the path, persist it into table state, and unlock credential-vending APIs for the same scope.

If the attacker-chosen path resolves to a broader prefix, another table's prefix, or a bucket root, the resulting credentials extend disclosure or corruption to any data and metadata Polaris can reach within that scope. Disabling the unstructured-locations flag reduces the credential-vending variant but does not remove the underlying pre-write validation gap.

Root Cause

The defect is missing input validation [CWE-20] in the settings-change code path. Polaris skips the location allowlist enforcement that normally runs during commit when only the write.metadata.path property is modified.

Attack Vector

An authenticated principal with permission to alter table properties issues a settings change that sets write.metadata.path to a reachable storage URI included in allowedLocations. Polaris writes new metadata to that URI without revalidating it. With allow.unstructured.table.location=true, the path is persisted and subsequent loadTable and credential calls return temporary cloud credentials scoped to the attacker-controlled prefix.

The vulnerability is described in prose only; no public proof-of-concept code is published. See the Apache Mailing List Thread and the OpenWall OSS Security Discussion for vendor detail.

Detection Methods for CVE-2026-42812

Indicators of Compromise

• Audit log entries showing ALTER TABLE-style updates that modify write.metadata.path without accompanying data operations.
• Polaris metadata writes to storage prefixes that do not match the table's original location property.
• Token issuance from Polaris credential APIs scoped to prefixes outside the canonical table directory.
• Access patterns where a single principal alters write.metadata.path on multiple tables in a short window.

Detection Strategies

• Enable verbose audit logging on the Polaris catalog and parse property-change events for write.metadata.path mutations.
• Correlate cloud-storage access logs (S3, GCS, Azure Blob) against the table's original metadata location to flag drift.
• Alert on loadTable responses that return credentials for prefixes outside the registered table base path.

Monitoring Recommendations

• Forward Polaris and Iceberg REST catalog logs to a centralized SIEM with retention covering full table lifecycle.
• Monitor allowedLocations configuration drift and review any change that broadens the allowlist.
• Track per-principal frequency of table-property changes and baseline normal operator behavior.

How to Mitigate CVE-2026-42812

Immediate Actions Required

• Set polaris.config.allow.unstructured.table.location=false on all Polaris catalogs to block the persisted credential-vending variant.
• Narrow allowedLocations to the minimum set of prefixes required for legitimate table layouts.
• Restrict the MANAGE_GRANTS_ON_SECURABLE and table-alter privileges to a small set of trusted service accounts.
• Rotate any temporary cloud credentials issued by Polaris during the exposure window.

Patch Information

Apache has not listed specific fixed versions in the published advisory references. Track the Apache Mailing List Thread for the official patched release of Apache Polaris and apply it as soon as it is available. Until the patch ships, the configuration controls below limit the persisted impact.

Workarounds

• Disable allow.unstructured.table.location until a fixed Polaris release is deployed.
• Restrict catalog-level write permissions to bucket prefixes dedicated solely to Iceberg-managed tables.
• Implement storage-side bucket policies that reject writes from Polaris service principals to unexpected prefixes.
• Review existing tables for unexpected write.metadata.path values and reset them to canonical locations.

# Configuration example: harden Polaris catalog settings
polaris.config.allow.unstructured.table.location=false

# Constrain allowedLocations in catalog properties to specific prefixes
allowedLocations=s3://prod-iceberg-warehouse/db1/,s3://prod-iceberg-warehouse/db2/

# Audit existing tables for drift
SHOW TBLPROPERTIES catalog.db.table ('write.metadata.path');