Introduction
A single unescaped asterisk in a table name can turn Apache Polaris' delegated S3 credential mechanism into a skeleton key for your entire data lake. CVE-2026-42810, scored at CVSS 9.9, shows how a low-privilege user can craft wildcard table names and receive temporary S3 credentials that reach far beyond their intended scope. Those credentials grant read and write access to other tables' storage paths.
Apache Polaris is an open-source catalog for Apache Iceberg that implements the Iceberg REST API. It lets multiple engines work with the same tables, including Apache Spark, Apache Flink, Trino, Dremio, and StarRocks, so it is a central component in many data lake architectures. Because Polaris is the authoritative catalog for table metadata and also delegates credentials, a vulnerability in its access control logic has broad consequences.
Technical Information
The root cause of CVE-2026-42810 is an input validation and output encoding failure (CWE-20, CWE-116) in how Apache Polaris constructs temporary S3 IAM policies for delegated table access. When a client requests credentials to work with a table's underlying S3 storage, Polaris dynamically builds IAM policy documents that scope access to the table's specific S3 prefix. Polaris inserts the namespace and table names directly into the IAM resource ARN patterns and s3:prefix conditions within these policies.
Polaris does not validate or escape special characters in namespace and table names, so it accepts literal * characters. In S3 IAM policy evaluation, * is a wildcard that matches any sequence of characters. When Polaris embeds a table name such as *.* or foo.* in an IAM policy resource pattern, the resulting policy grants access to that table's own storage prefix and to any other prefix that matches the wildcard expression.
Attack Flow
The exploitation sequence is straightforward:
-
An attacker with namespace-scoped
TABLE_CREATEandTABLE_WRITE_DATApermissions creates a table with a crafted name containing asterisk characters, such as*.*,f*.t1,f*.*, orfoo.*. -
The attacker requests delegated S3 credentials for this crafted table through the Polaris REST API.
-
Polaris generates a temporary IAM policy that includes the unescaped asterisk in the S3 resource ARN and prefix conditions.
-
The resulting temporary credentials have a far broader effective scope than intended and match storage paths that belong to other tables.
-
The attacker uses these credentials to perform S3 operations against victim tables' storage locations.
Confirmed Impact
Private testing against Polaris 1.4.0, on both MinIO and real AWS S3, confirmed the following capabilities for crafted table names:
| Crafted Table Name | Storage Backend | Observed Capabilities |
|---|---|---|
f*.t1 | AWS S3, MinIO | Read metadata JSON, list prefix, create/delete objects |
f*.* | AWS S3, MinIO | Read metadata JSON, list prefix, create/delete objects |
*.* | AWS S3, MinIO | Read metadata JSON, list prefix, create/delete objects |
foo.* | AWS S3, MinIO | Read metadata JSON, list prefix, create/delete objects |
A control case with ordinary table names and no asterisks did not permit the same cross-table access, which confirms that the wildcard character is the differentiating factor.
The confirmed behaviors include:
- Reading another table's Iceberg metadata JSON file. This control file tells readers which data files belong to the table, which snapshots exist, and which table version to read, so unauthorized access to it is a meaningful confidentiality breach on its own.
- Listing another table's exact S3 table prefix, which exposes the structure and contents of the victim table's storage.
- Creating and deleting objects under another table's exact S3 table prefix, when Polaris returned write delegation for the crafted table. This confirms that the vulnerability goes beyond information disclosure into integrity compromise.
Least-Privilege Bypass
In the least-privilege variant of this attack, the attacker principal had zero Polaris permissions on the victim table. It held only the minimal permissions needed to create and use a crafted wildcard table: namespace-scoped TABLE_CREATE and TABLE_WRITE_DATA on *. Direct Polaris API access to the victim table (for example, foo.t1) remained forbidden. The attacker could still create and load *.*, receive delegated S3 credentials, and use them to list, read, create, and delete objects under foo.t1's storage path. That is a complete bypass of Polaris' authorization model at the storage layer.
Affected Systems and Versions
The vulnerability has been confirmed in Apache Polaris 1.4.0. Based on the nature of the flaw, all versions before 1.4.1 are considered affected. Apache Polaris 1.4.1, released on May 1, 2026, contains the fix.
The vulnerability specifically affects deployments that use Polaris' AWS S3 temporary credential delegation path. Testing covered both MinIO and real AWS S3 backends. Organizations running platforms that embed Polaris, such as Dremio, should also verify their exposure and apply the corresponding vendor updates.
Vendor Security History
Apache Polaris 1.4.1 fixed four security issues at once, which suggests a focused security review of the credential delegation subsystem:
| CVE Identifier | Description | Fixed Version |
|---|---|---|
| CVE-2026-42809 | Abuse of staged table creation to mint broad temporary storage credentials | 1.4.1 |
| CVE-2026-42810 | Unescaped asterisk characters in S3 IAM resource patterns | 1.4.1 |
| CVE-2026-42811 | Crafted names causing GCS credentials to work across the configured bucket | 1.4.1 |
| CVE-2026-42812 | No protection on write metadata path | 1.4.1 |
Four related vulnerabilities in one release indicate that credential scoping and storage path isolation were systemic weaknesses in the Polaris codebase before 1.4.1.
