CVE-2026-42810
Awaiting Analysis Awaiting Analysis - Queue
Polaris S3 Access Policy Wildcard Injection

Publication date: 2026-05-04

Last updated on: 2026-05-04

Assigner: Apache Software Foundation

Description
Apache Polaris accepts literal `*` characters in namespace and table names. When it later builds temporary S3 access policies for delegated table access, those same characters appear to be reused unescaped in S3 IAM resource patterns and `s3:prefix` conditions. In S3 IAM policy matching, `*` is treated as a wildcard rather than as ordinary text. That means temporary credentials issued for one crafted table can match the storage path of a different table. In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary- credential path on both MinIO and real AWS S3, credentials returned for crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other tables' S3 locations. The confirmed behavior includes: - reading another table's metadata control file ([Iceberg metadata JSON]); - listing another table's exact S3 table prefix ([table prefix]); - and, when write delegation was returned for the crafted table, creating and deleting an object under another table's exact S3 table prefix. A control case using ordinary different names did not allow the same cross-table access. A least-privilege AWS S3 variant was also confirmed in which the attacker principal had no Polaris permissions on the victim table and only the minimal permissions required to create and use a crafted wildcard table (namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that setup, direct Polaris access to `foo.t1` remained forbidden, but the attacker could still create and load `*.*`, receive delegated S3 credentials, and use those credentials to list, read, create, and delete objects under `foo.t1`. In Iceberg, the metadata JSON file is a control file: it tells readers which data files belong to the table, which snapshots exist, and which table version to read. So unauthorized access to it is already a meaningful confidentiality problem. The confirmed write-capable variant means the issue is not limited to disclosure.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-04
Last Modified
2026-05-04
Generated
2026-05-07
AI Q&A
2026-05-05
EPSS Evaluated
2026-05-05
NVD
CVE-2026-42810
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
apache polaris From 1.4.0 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-20 The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
CWE-116 The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows unauthorized access to sensitive metadata and data files across different tables in Apache Polaris, including the ability to read, list, create, and delete objects in other tables' S3 storage locations.

Such unauthorized access to confidential data and the ability to modify it can lead to violations of data protection regulations and standards like GDPR and HIPAA, which require strict controls on data confidentiality, integrity, and access.

Because the vulnerability enables cross-table data exposure and modification despite least-privilege permissions, it poses a significant risk to compliance with these regulations.


Can you explain this vulnerability to me?

This vulnerability exists in Apache Polaris where literal '*' characters are accepted in namespace and table names. When Polaris builds temporary S3 access policies for delegated table access, these '*' characters are reused unescaped in S3 IAM resource patterns and conditions.

In S3 IAM policy matching, '*' is treated as a wildcard, not as ordinary text. This allows temporary credentials issued for one specially crafted table name containing '*' to match and access the storage paths of different tables.

Testing showed that credentials for crafted tables like 'f*.t1', 'f*.*', '*.*', and 'foo.*' could access other tables' S3 locations, including reading metadata files, listing table prefixes, and even creating or deleting objects under other tables' prefixes.

This means unauthorized cross-table access is possible, violating expected access controls.


How can this vulnerability impact me? :

This vulnerability can lead to unauthorized access to other tables' data stored in S3, including sensitive metadata files that control which data files belong to a table and its versions.

An attacker could read confidential metadata, list contents of other tables, and if write permissions are delegated, create or delete objects in other tables' storage locations.

Such unauthorized read and write access compromises data confidentiality and integrity, potentially leading to data leakage, tampering, or loss.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart