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, demonstrates how a low-privilege user can craft wildcard table names to receive temporary S3 credentials that reach far beyond their intended scope, granting 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 enables multi-engine interoperability across platforms including Apache Spark, Apache Flink, Trino, Dremio, and StarRocks, making it a central component in many modern data lake architectures. Its position as the authoritative catalog for table metadata and credential delegation means a vulnerability in its access control logic has broad implications.
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 interact with a table's underlying S3 storage, Polaris dynamically builds IAM policy documents that scope access to the table's specific S3 prefix. The namespace and table names are inserted directly into the IAM resource ARN patterns and s3:prefix conditions within these policies.
Polaris performs no validation or escaping of special characters in namespace and table names. It accepts literal * characters. In the context of S3 IAM policy evaluation, * is a wildcard that matches any sequence of characters. When a table named *.* or foo.* has its name embedded into an IAM policy resource pattern, the resulting policy grants access not just to that table's storage prefix, but to any 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 an effective scope far broader than intended, matching storage paths belonging to other tables.
-
Using these credentials, the attacker performs 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 when using 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 using ordinary table names without asterisks did not permit the same cross-table access, confirming the wildcard character is the differentiating factor.
The confirmed behaviors include:
- Reading another table's Iceberg metadata JSON file. This is a control file that tells readers which data files belong to the table, which snapshots exist, and which table version to read. Unauthorized access to this file alone represents a meaningful confidentiality breach.
- Listing another table's exact S3 table prefix, exposing the structure and contents of the victim table's storage.
- Creating and deleting objects under another table's exact S3 table prefix when write delegation was returned for the crafted table. This confirms the vulnerability extends beyond information disclosure into integrity compromise.
Least Privilege Bypass
The least privilege variant of this attack is particularly notable. In this scenario, the attacker principal had zero 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 *. Direct Polaris API access to the victim table (for example, foo.t1) remained forbidden. However, the attacker could create and load *.*, receive delegated S3 credentials, and use those credentials to list, read, create, and delete objects under foo.t1's storage path. This demonstrates 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 prior to 1.4.1 are considered affected. The fix was released in Apache Polaris 1.4.1 on May 1, 2026.
The vulnerability specifically affects deployments using Polaris' AWS S3 temporary credential delegation path. Testing was performed against both MinIO and real AWS S3 backends. Organizations using platforms that embed Polaris, such as Dremio, should also verify their exposure and apply corresponding vendor updates.
Vendor Security History
The release of Apache Polaris 1.4.1 addressed four security issues simultaneously, suggesting 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 |
This cluster of related vulnerabilities indicates that credential scoping and storage path isolation were systemic weaknesses in the Polaris codebase prior to 1.4.1.
