Apache Polaris CVE-2026-42809: Brief Summary of Critical Credential Vending Bypass in Staged Table Creation

Introduction

An authenticated user with minimal privileges can trick Apache Polaris into minting temporary storage credentials for any reachable storage location they choose. All it takes is a crafted location during staged table creation. The vulnerability has a CVSS 3.1 base score of 9.9, and its scope change extends the impact beyond the vulnerable component. It is a serious credential scoping failure in the data catalog's delegated access model.

Apache Polaris is an open-source, fully featured catalog for managing tabular data, commonly used in modern data lakehouse architectures. It is the reference implementation of the Apache Iceberg REST Catalog specification, and downstream vendors bundle it, including Dremio in its Open Catalog offering. Because Polaris acts as a central authority for table metadata and credential delegation, flaws in its access control logic carry more weight than they would in most components.

Technical Information

Root Cause

CVE-2026-42809 comes from two weaknesses that meet in the staged table creation workflow of Apache Polaris: improper input validation (CWE-20) and missing authorization (CWE-862). When a client starts a staged table creation and requests credential vending, Polaris is designed to issue temporary ("vended") storage credentials scoped to the table's effective location. That scoping is meant to limit what data and metadata the credential holder can access.

The stage create code path issues these delegated storage credentials before the effective table location has been validated or durably reserved. The caller can supply their own location parameter, and Polaris builds the credential scope from that attacker-supplied value immediately. The location validation and overlap checks that would normally stop a user from naming an arbitrary storage path do not run before Polaris hands back the credentials.

CVSS Scoring

The vulnerability is scored under both frameworks:

The scope change (S:C in CVSS 3.1) reflects that a flaw in the Polaris catalog component lets the attacker affect resources in the underlying storage layer, which is a separate authorization boundary.

Exploit Path 1: Custom Location with Credential Vending

This is the primary confirmed variant. The attack works like this:

1. An authenticated user with low privileges (enough to create staged tables) sends a stage create request to the Polaris REST API.
2. The request includes a custom location parameter pointing to an attacker-chosen storage path, such as a path holding sensitive data that belongs to another table or namespace.
3. The request also enables credential vending and asks Polaris to return temporary storage credentials.
4. Polaris builds delegated storage credentials scoped to the attacker-supplied location and returns them in the response.
5. The stage create path does not run the normal location validation or overlap checks before issuing these credentials.
6. The attacker now holds valid temporary credentials (for example, scoped AWS STS tokens or GCS access tokens) that grant read and write access to the target location.

Because the attacker chooses the location, the "scope limitation" meant to restrict credentials to a single table's data is set entirely by the attacker.

Exploit Path 2: Write Path Property Overrides

The staged create flow also accepts write.data.path and write.metadata.path in the request properties. Polaris feeds these location overrides into the same effective table location set it uses for credential vending. These fields are secondary to the custom location exploit, but they give the attacker more attacker-influenced location inputs that skip validation before credentials are issued.

An attacker could use these properties on their own or together with the custom location parameter to widen the scope of the vended credentials further and reach metadata storage paths that would otherwise be restricted.

Impact

Successful exploitation affects all three impact areas:

• Confidentiality: The attacker gets temporary credentials scoped to arbitrary storage locations and can read sensitive data across the connected object storage without authorization.
• Integrity: The same credentials grant write access, so the attacker can modify or corrupt data and metadata at the target location.
• Availability: Writing data and metadata before validation runs can disrupt operations or corrupt the storage environment.

Detection Opportunities

Organizations should monitor request logs for stage create calls that set location, write.data.path, or write.metadata.path properties while also enabling credential vending. Unusual access to nonstandard storage locations using temporary credentials may indicate active exploitation.

Affected Systems and Versions

All versions of Apache Polaris before 1.4.1 are affected. Apache Polaris 1.4.1 contains the fix and is available on Maven Central and Docker Hub.

Downstream products that bundle Apache Polaris are also affected. Dremio, which uses the Polaris catalog in its Open Catalog feature, released version 26.1.7 in May 2026 to address CVE-2026-42809 and three related Polaris vulnerabilities.

Organizations should list every service and application that exposes the Apache Polaris staged create and credential vending functionality, including downstream dependencies that may need separate patching.

Vendor Security History

Apache Polaris 1.4.1 fixes four security issues at once, all of them delegated credential scoping flaws:

Together, the four vulnerabilities point to a systemic class of risk in delegated access control and credential scoping within the 1.4.0 line of Apache Polaris. The cluster suggests that the credential vending subsystem's input handling had not received adversarial review before these disclosures.

References

• Apache Polaris Advisory for CVE-2026-42809
• oss-security Mailing List Disclosure
• CVE Record: CVE-2026-42809
• NVD Entry for CVE-2026-42809
• Apache Polaris 1.4.1 Release Announcement
• Dremio 26.x Release Notes