CVE-2026-64640: Apache Polaris Information Disclosure Flaw

CVE-2026-64640 Overview

Apache Polaris contains an authorization flaw that allows authenticated principals to bypass storage location validation during table and view registration. The vulnerability is tracked under CWE-863: Incorrect Authorization. An attacker with registration privileges can direct Polaris to read arbitrary Iceberg metadata files using the catalog's storage credentials before boundary checks execute. Exploitation requires an S3 credential vending deployment and a target object readable by the catalog's underlying credentials outside allowed locations. The demonstrated impact is limited to confidentiality, with no data modification or availability effects observed.

Critical Impact
Authenticated attackers with table or view registration privileges can trigger server-side reads of Iceberg metadata files outside the catalog's allowed storage boundaries, disclosing limited object information.

Affected Products

Apache Polaris (catalog service for Apache Iceberg)
Deployments configured with S3 credential vending
Catalogs whose underlying storage credentials can access objects outside allowed locations

Discovery Timeline

2026-08-06 - CVE-2026-64640 published to NVD
2026-08-06 - Last updated in NVD database

Technical Details for CVE-2026-64640

Vulnerability Analysis

Apache Polaris is a catalog service for Apache Iceberg tables and views. The service accepts registration requests containing a storage location for an existing Iceberg metadata file. Polaris then reads that metadata to register the table or view within the catalog. The vulnerability stems from inconsistent enforcement of the catalog's allowed storage location boundary during this registration flow.

An authenticated principal holding table or view registration permission can supply a caller-selected metadata path. Depending on the release and registration path, Polaris reads the referenced file using catalog storage credentials before verifying the path falls within the catalog's allowed locations. If the credentials can access objects outside that boundary, the server performs an out-of-bounds read and may return limited object information to the caller.

A secondary condition allows registration of metadata files that reside within an allowed location but reference external storage locations. Polaris does not follow those references during registration, so this condition does not itself trigger external reads.

Root Cause

The root cause is an ordering flaw in the authorization logic. Polaris uses privileged catalog credentials to fetch caller-supplied Iceberg metadata before validating that the object path is within the catalog's allowed storage locations. This violates the principle of complete mediation for storage boundary checks.

Attack Vector

Exploitation occurs over the network against a Polaris deployment using S3 credential vending. The attacker authenticates as a principal with table or view registration privileges. The attacker submits a registration request that references an Iceberg metadata object outside the catalog's allowed storage locations. Polaris uses its own storage credentials to read the file, and details from the object contents may be disclosed to the caller.

No verified exploit code is publicly available. The vulnerability mechanism is described in the Apache Thread Discussion.

Detection Methods for CVE-2026-64640

Indicators of Compromise

Polaris audit log entries recording table or view registration calls that reference storage paths outside configured catalog allowed locations.
S3 access logs showing catalog credential reads of objects outside expected prefixes shortly after registration API calls.
Registration requests originating from principals that seldom perform registration operations.

Detection Strategies

Correlate Polaris registration API activity with downstream S3 GetObject calls made by the catalog's IAM role, flagging reads outside allowed prefixes.
Alert on registration attempts where the supplied metadata path does not share a prefix with any configured allowed storage location for the catalog.
Track registration frequency and principal identity to surface anomalous behavior against baseline patterns.

Monitoring Recommendations

Forward Polaris server logs and S3 CloudTrail data events into a centralized analytics platform for cross-source correlation.
Monitor IAM policy scope on the catalog role and continuously verify that its permissions do not extend beyond intended storage locations.
Review registration grants regularly and remove the privilege from principals that do not require it.

How to Mitigate CVE-2026-64640

Immediate Actions Required

Upgrade Apache Polaris to a fixed release once available from the Apache Polaris project.
Restrict table and view registration privileges to a minimal set of trusted principals.
Tighten the IAM policy attached to the catalog's storage credentials so it can only access objects within the allowed locations.

Patch Information

Refer to the Apache Thread Discussion for the official advisory and fixed version information. Apply the patched Polaris release as soon as it becomes available in your deployment channel.

Workarounds

Scope the S3 credentials vended to Polaris using bucket policies and IAM conditions that limit access strictly to the catalog's allowed prefixes.
Audit and revoke unnecessary table or view registration permissions across all principals until the patch is deployed.
Enable detailed S3 access logging and Polaris audit logging to detect attempted out-of-boundary reads.

bash

# Example IAM policy restricting catalog credentials to allowed prefix only
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::catalog-bucket/allowed-prefix/*"
    }
  ]
}