Description

Apache Polaris did not consistently validate storage locations supplied during table and view registration. An authenticated principal with permission to register a table or view could, depending on the affected release and registration path, cause Polaris to use the catalog's storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog's allowed storage locations. If the catalog's underlying credentials could read an object outside that boundary, this could disclose limited information from the object. Polaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary. This second condition did not itself cause Polaris to read the referenced external locations during registration. The demonstrated impact is limited to confidentiality. No unauthorized data modification or availability impact has been demonstrated. The server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog's underlying storage credentials can read. Exploitation requires an authenticated principal with table- or view-registration privileges.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-06T09:16:36.797Z",
  "pubdate": "2026-08-06T09:16:36.797Z",
  "executiveSummary": "Apache Polaris contains a vulnerability involving insufficient validation of storage locations supplied during table and view registration.\nThe vulnerability allows an authenticated principal with table or view registration permissions to cause the catalog to utilize its underlying storage credentials to read a caller-selected Apache Iceberg metadata file before verifying whether the file resides within the catalog's permitted storage boundaries.\nIf the underlying storage credentials possess access to objects outside the designated security boundary, this behavior can result in limited information disclosure via server-side reads.\nAdditionally, Polaris can accept registration metadata residing within an allowed location that contains references to external storage locations outside the permitted boundary, though this secondary condition does not independently trigger reads of those external locations during the registration process.\nThe demonstrated impact is strictly restricted to confidentiality, with no unauthorized data modification or availability impacts demonstrated.\nExploitation requires specific environmental conditions, including a deployment utilizing S3 credential vending, an authenticated principal possessing table- or view-registration privileges, and the existence of an external object outside allowed locations accessible by the catalog's storage credentials.",
  "technicalDetails": "The root cause of the vulnerability stems from inconsistent validation checks performed on user-supplied storage locations during the table and view registration paths in Apache Polaris.\nAuthentication and privilege requirements dictate that an attacker must possess an authenticated principal with explicit permissions to register a table or view within the catalog.\nThe attack flow proceeds when an authenticated user supplies a crafted storage location or registers metadata containing references during the table or view registration process.\nDepending on the affected release and the specific registration path invoked, Polaris initiates a server-side read of a caller-selected Apache Iceberg metadata file using the catalog's storage credentials prior to completing boundary verification checks against the catalog's allowed storage locations.\nIn deployments utilizing S3 credential vending, if the catalog's underlying storage credentials possess permissions to read objects situated outside the defined security boundaries, the server-side read executes successfully against the out-of-bounds target.\nThis behavior can lead to limited information disclosure of data contained within the targeted external object.\nA secondary vector involves Polaris accepting registration metadata situated within a legitimately allowed location that embeds references to storage locations outside the allowed boundary; however, this specific condition does not automatically trigger reads of the referenced external locations during the registration phase.\nThe post-exploitation impact is limited exclusively to confidentiality breaches, as neither data modification nor availability degradation vectors are supported or demonstrated by this flaw."
}