Apache Polaris

Polaris 1.6.0 (July 8, 2026) — a monthly release train is now established. The release hardens the credential-vending path it was attacked through in May: the new SESSION_NAME_FIELDS_IN_SUBSCOPED_CREDENTIAL flag composes structured AWS STS role session names from an ordered field list (realm, catalog, namespace, table, principal — sanitized and truncated to AWS's 64-char limit), giving audit trails a deterministic identity string per vended credential. Operational boundaries were also formalized: event listeners now run on a dedicated executor (deliberately dropping request-context propagation), and the REST layer strictly rejects entity names containing control characters, whitespace padding, or forbidden characters. Per Apache Polaris 1.6.0 downloads and the 1.6.0 announce thread.

Graduated to ASF Top-Level Project (February 2026) — and Cloudera adopted it. TLP status (100+ contributors, 2,800+ closed PRs) was the vendor-neutrality signal enterprises were waiting on, mirroring Iceberg's own path. Cloudera's June 2026 adoption came with code: Cloudera contributed the Apache Ranger authorizer plugin that shipped in 1.5.0. Community discussion has moved past "is it viable" to semantic layers, lineage, and AI agent serving — the catalog's next-surface debate. Per The State of Apache Polaris in July 2026 (Alex Merced) and Apache Polaris: The Open Standard Iceberg Catalog (Sparking Scala).

1.5.0 also shipped BigQuery Metastore federation and the phantom-grants fix. Federation reads schema + location from BigQuery Metastore and projects them as standard Iceberg REST endpoints — engines can join GCS-resident Iceberg tables with BigQuery-managed tables through one Polaris catalog, no metadata copying. Stale grants tied to deleted grantees are now filtered automatically during metadata resolution. Per Dremio — Apache Polaris 1.5.0 deep dive.

Apache Polaris's first serious security reckoning: a four-CVE credential-vending cluster disclosed May 4, 2026, all fixed in 1.4.1. The lead flaw, CVE-2026-42810 (CVSS 4.0 9.4 / CVSS 3.1 9.9), is an S3 IAM policy bypass via wildcard table names: an attacker holding only namespace-scoped TABLE_CREATE + TABLE_WRITE_DATA on * creates a table whose name contains literal wildcard characters (e.g. f*.t1, *.*), which Polaris passes unescaped into the generated S3 resource patterns and s3:prefix conditions, so the vended temporary credentials match other tables' object paths — enabling unauthorized list/read/create/delete of any table's S3 objects and Iceberg metadata with no direct Polaris permission on the victim table. Per CVE-2026-42810 (ThreatInt).

The root cause is the credential-vending path itself, not a single bug — three sibling CVEs share it. CVE-2026-42809 (9.4/9.9) vends over-broad temporary credentials during staged table creation, before the effective table location is validated or durably reserved, letting a low-privileged attacker steer credential scope via attacker-supplied write.data.path/write.metadata.path; CVE-2026-42812 (9.4/9.9) lets a user with table-alter rights set write.metadata.path to bypass the commit-time storage-location revalidation and force metadata writes (and credential vending) to an attacker-chosen location; CVE-2026-42811 (9.4/9.9) is the GCS analogue of 42810 — unescaped namespace/table identifiers (with CEL fragments and a single quote) collapse the Credential Access Boundary CEL path restriction, minting effectively bucket-wide GCS credentials. All four are fixed in Polaris 1.4.1. Per GHSA-w76p-3cgp-qfcm · Apache Polaris metadata write bypass (GitHub Advisory).

Apache Polaris tools repo ships Iceberg Catalog Migrator CLI + performance benchmarks. Per the apache/polaris-tools repository, the official tools project now hosts both performance benchmarks and an Iceberg Catalog Migrator CLI for moving tables between catalogs (Polaris ↔ Glue / Hive Metastore / Unity Catalog / Nessie). Catalog-migration tooling is the load-bearing piece for any organization committing to Polaris in 2026 — the question shifts from "will Polaris support migrations" to "how much does the migrator handle automatically."

Apache Ranger authorization plugin RFC in flight. Per the Apache Data Lakehouse Weekly (March 16 – April 2, 2026), Selvamohan Neethiraj opened an RFC for an Apache Ranger authorization plugin for Apache Polaris — bringing enterprise-grade policy integration to the open Iceberg REST Catalog reference implementation. The Ranger integration closes the "Unity Catalog has governance, Polaris doesn't" gap that has been the main reason enterprises picked UC over Polaris — and it shipped as Beta in Polaris 1.5.0 (see below).

Polaris 1.5.0 (May 18, 2026) turns the catalog into a control plane — and closes the governance gap. The release adds BigQuery Metastore federation (Polaris serves a unified Iceberg REST interface over tables managed in BigQuery Metastore), extends credential vending to the Generic Table API (new Polaris-Generic-Table-Access-Delegation header — short-lived, prefix-scoped storage credentials now cover non-Iceberg datasets, not just Iceberg tables), and refactors authorization into a fully pluggable Authorizer SPI (request-scoped AuthorizationRequest / AuthorizationDecision interfaces that separate the access decision from Polaris's internal principal resolution). The headline payoff is Apache Ranger support (Beta) — the enterprise-policy integration that had been the main reason organizations reached for Unity Catalog instead. Per Snowflake — Apache Polaris 1.5 Release and Apache Polaris 1.5.0 downloads.

The agent-safe catalog boundary, now multimodal via Lance (June 2026 wave). As the API boundary deciding whether agents reach data without human oversight, Polaris vends short-lived credentials and remote-signs S3 access; its Generic Table API integrates the Lance format so relational and multimodal/vector data sit under one governed catalog. Per Apache Polaris + Lance integration.