Four Critical Apache Polaris Vulnerabilities (CVSS 9.9) Allow Cloud Storage Credential Hijacking

Four critical vulnerabilities — CVE-2026-42809, CVE-2026-42810, CVE-2026-42811, and CVE-2026-42812 — in Apache Polaris 1.4.0 and earlier allow an authenticated attacker to manipulate the platform's credential vending system and gain unauthorized access to cloud storage data across Amazon S3 and Google Cloud Storage buckets. All four flaws carry a CVSS v3.1 score of 9.9 out of 10 (Critical — remotely exploitable with low privilege required, no user interaction, and full impact on confidentiality, integrity, and availability across affected systems). Apache Polaris 1.4.1, released May 1, 2026, contains the fixes; teams running self-managed Polaris deployments must upgrade immediately.

// 01 Apache Polaris Credential Vending: Technical Details

Apache Polaris is an open-source, fully conformant implementation of the Apache Iceberg REST Catalog specification — a standard interface for managing large-scale analytical data tables stored in cloud object storage. Organizations running data lakehouse architectures on AWS S3 or Google Cloud Storage use Polaris as the central catalog: it tracks table schemas, partition layouts, and snapshot history, and it acts as a credential broker through a mechanism called "credential vending."

Credential vending is the process by which Polaris issues short-lived, scoped cloud storage credentials to query engines — Apache Spark, Trino, Flink, and others — so they can access specific table data without holding long-lived storage keys. A query engine calls the Polaris API, requests access to table A, and receives an AWS STS token (a short-lived, narrowly scoped AWS credential) or a GCS access token restricted to that table's storage prefix. The security model depends entirely on Polaris correctly computing the scope of those tokens.

All four CVEs represent failures of this isolation guarantee, all confirmed against Polaris 1.4.0 on both MinIO (an S3-compatible on-premises object store) and production AWS S3 environments.

CVE-2026-42809 (CVSS v3.1: 9.9, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H; CVSS 4.0: 9.4): During staged table creation — a two-step create-then-commit workflow in the Iceberg specification — Polaris issues vended storage credentials before it has validated or durably reserved the effective table location. If the caller supplies a custom location parameter in the stage-create request, Polaris uses that attacker-controlled path to construct delegated storage credentials immediately, bypassing both location validation and overlap checks. An attacker can supply any reachable storage path and receive valid, scoped credentials for it.

CVE-2026-42810 (CVSS 9.9, S3-specific): When generating IAM resource patterns and s3:prefix conditions for credential downscoping, Polaris does not escape wildcard characters present in table names. An attacker who creates a table with a name containing literal * characters causes Polaris to embed those wildcards verbatim into the generated S3 IAM policy, expanding the credential scope to match — and grant read/write access to — the S3 storage paths of other tables.

CVE-2026-42811 (CVSS 9.9, GCS-specific): A crafted namespace or table name causes Polaris to issue Google Cloud Storage credentials with bucket-wide scope rather than restricting access to the intended table's file prefix. An attacker can effectively obtain credentials that unlock an entire GCS bucket, not just the single table's data.

CVE-2026-42812 (CVSS 9.9): An authenticated user with permission to change table settings can bypass Polaris's storage location validation checks and force the catalog to write sensitive Iceberg table metadata — including schema definitions, partition specifications, and column statistics — to an arbitrary, attacker-chosen storage location. Polaris then vends cloud storage credentials scoped to that attacker-chosen location, compounding the data exposure.

// 02 Exploitation Status and Threat Landscape

No public proof-of-concept (PoC — working exploit code) exists for any of the four CVEs at the time of writing. All four vulnerabilities require an authenticated account on the Polaris instance with at least table-creation or table-settings modification permissions. This prerequisite reduces the immediate risk from anonymous internet attackers, but it is significant for multi-tenant data platforms where separate teams or customers share a single Polaris deployment and hold varying privilege levels.

None of CVE-2026-42809, CVE-2026-42810, CVE-2026-42811, or CVE-2026-42812 has been added to the CISA KEV catalog (the U.S. Cybersecurity & Infrastructure Security Agency's Known Exploited Vulnerabilities list — a catalog that confirms active exploitation in the wild). There are no confirmed reports of exploitation at this time.

The most applicable MITRE ATT&CK (a globally recognized framework of adversary tactics and techniques) classification is T1530 — Data from Cloud Storage, which covers adversary access to cloud object storage buckets to collect sensitive business data, source code, credentials, and other high-value assets. The staged-create bypass of CVE-2026-42809 additionally maps to T1078.004 — Valid Accounts: Cloud Accounts, as the attacker abuses a legitimate low-privilege account to escalate storage access beyond their authorization.

// 03 Who Is Affected

Any organization running Apache Polaris 1.4.0 or earlier as an Iceberg catalog is affected. Private testing confirmed exploitation on Polaris 1.4.0 on both MinIO and real AWS S3 environments. Affected deployment types include:

• Self-managed Apache Polaris deployments in cloud data lakehouse architectures
• Kubernetes-based Polaris deployments accessing cloud storage via workload identity or static credentials
• Organizations using Apache Polaris with Amazon S3 as their underlying Iceberg storage
• Organizations using Apache Polaris with Google Cloud Storage as their underlying Iceberg storage

The blast radius of these vulnerabilities scales with the cloud permissions granted to the Polaris service account. In environments where the Polaris service account has access to multiple S3 buckets or GCS buckets containing sensitive data — financial records, PII, intellectual property, proprietary analytics — credential hijacking via CVE-2026-42809 or credential scope expansion via CVE-2026-42810 and CVE-2026-42811 could expose that data directly.

There is no public exposure count (Shodan index) for Apache Polaris, as it is typically deployed as an internal service rather than a public-facing API. However, Polaris has seen rapid enterprise adoption as the reference catalog for Iceberg-based lakehouses; Snowflake's engineering blog noted the Polaris 1.4 release as a significant milestone, indicating broad production use.

// 04 What You Should Do Right Now

• Upgrade to Apache Polaris 1.4.1 immediately. Download the release from the official Apache Polaris downloads page. Released May 1, 2026, version 1.4.1 contains improved storage URI handling, location validation, and staged table handling that address all four CVEs.

• Audit credential vending logs for anomalous staged-create requests. Review Polaris audit logs for table creation events with custom location parameters pointing to prefixes outside your known data layout. Any location values that don't match your organization's expected storage path patterns warrant investigation.

• Inspect your catalog for wildcard characters in table and namespace names. Search existing table names for *, ?, or other glob characters — these should not appear in legitimate table names and may indicate prior exploitation of CVE-2026-42810 or CVE-2026-42811.

“bash # Example: query Polaris REST API for tables with wildcard characters curl -s -H "Authorization: Bearer $POLARIS_TOKEN" "$POLARIS_URL/api/catalog/v1/$CATALOG/namespaces/$NS/tables" | jq '.identifiers[].name | select(contains("*") or contains("?"))' “

• Apply least-privilege IAM policies to the Polaris service account. If the Polaris service account holds overly broad S3 permissions (for example, s3:* on the entire bucket), scope them down to only the prefixes Polaris legitimately manages. This limits the damage from any successful credential scope bypass.

• Restrict table-creation and table-settings permissions on shared deployments. In multi-tenant Polaris instances, limit which principals have permission to create tables with custom locations or modify table settings. Review existing role bindings against the principle of least privilege.

• Isolate Polaris deployments by trust boundary. If immediate upgrade is not possible, consider running separate Polaris instances for separate teams or external customers rather than sharing a single deployment across multiple trust levels.

// 05 Background: Understanding the Risk

Apache Polaris sits between query engines and cloud object storage, acting as both the source of truth for table metadata and as a credential broker that controls what data each query engine can access. This architectural position makes Polaris a high-value security boundary: a flaw in its credential vending logic gives an attacker access not just to table metadata, but to the underlying cloud storage itself.

The credential vending pattern exists precisely to avoid distributing long-lived storage keys to query engines. Instead of configuring every Spark cluster with an AWS access key, operators configure Polaris with a service account that has broad storage access, then let Polaris issue narrowly scoped, short-lived tokens to query engines on demand. The security improvement over static credentials depends entirely on Polaris correctly computing those narrow scopes.

CVE-2026-42809 breaks the staged-create path by issuing credentials before the location is validated. CVE-2026-42810 breaks the S3 credential downscoping by failing to sanitize wildcard characters. CVE-2026-42811 breaks GCS credential downscoping via the same input-handling failure applied to namespace and table names. CVE-2026-42812 breaks the metadata write path's location guard, allowing metadata to be redirected to attacker-controlled storage. In each case, the root cause is a failure to enforce the same location-validation logic consistently across all code paths that interact with storage credentials.

The Iceberg ecosystem has grown significantly in enterprise environments precisely because of features like credential vending, schema evolution, and time-travel queries. Apache Polaris 1.4.1's release notes describe improvements to "storage URI handling," "locations-handling," and "staged table handling" — the exact subsystems affected by these four CVEs — confirming that the upgrade addresses all reported issues.

For teams using managed catalog services built on top of Polaris rather than self-hosting, contact your vendor to confirm which underlying Polaris version is deployed and whether it has been updated to 1.4.1 or a backported equivalent patch.

// 06 Conclusion

Four CVSS 9.9 vulnerabilities in the same credential vending subsystem represent an unusually concentrated attack surface. Organizations running self-hosted Apache Polaris 1.4.0 or earlier must upgrade to 1.4.1 immediately and audit both IAM policies and table name inventories for signs of prior abuse. While no public exploits exist yet, the authentication prerequisite is low and the data exposure potential is severe in any multi-tenant or data-rich deployment.