Introduction
A single unescaped quote character in a table name can turn Apache Polaris's carefully scoped GCS credentials into a skeleton key for an entire cloud storage bucket. CVE-2026-42811, scored at CVSS 9.9, is a CEL expression injection in Apache Polaris that collapses the Credential Access Boundary meant to restrict temporary GCS tokens to a single Iceberg table's files, granting the holder read, write, list, and delete access across every prefix in the configured bucket.
Apache Polaris is the vendor neutral, open source implementation of the Iceberg REST Catalog API, recently graduated to an Apache Top Level Project. It is used by Snowflake as the interoperability layer for its Horizon Catalog and by Fivetran as the foundation of its Iceberg REST Catalog across S3, ADLS, GCS, and OneLake destinations. Its position as shared infrastructure across major data platforms makes this vulnerability particularly consequential.
Technical Information
Root Cause: Unescaped Input in CEL Expression Construction
The vulnerability is classified under CWE-917 (Improper Neutralization of Special Elements used in an Expression Language Statement) and CWE-20 (Improper Input Validation).
When a client requests access to a table, Polaris constructs a Google Cloud Storage Credential Access Boundary (CAB) that contains a Common Expression Language (CEL) condition. This CEL condition is intended to restrict the resulting temporary credentials so they only work against the storage path associated with the requested table. The CEL string is built from two inputs: the bucket name and the table path. The table path is derived from the namespace and table identifiers supplied by the client.
In versions prior to 1.4.1, the table path is inserted into the CEL expression without escaping. Because CEL uses single quotes to delimit string literals, a namespace or table identifier containing a single quote character, followed by additional URI safe CEL syntax, can terminate the intended string literal prematurely. The injected CEL fragments then become part of the expression logic itself, altering the condition so that the path restriction is effectively removed.
Attack Flow
The exploitation sequence works as follows:
-
Craft the identifier. An attacker who can create namespaces or tables in a Polaris catalog constructs a namespace or table name that contains a single quote and CEL fragments designed to neutralize the path condition.
-
Request credentials. The attacker issues a standard credential vending request to Polaris for the crafted table. Polaris does not validate or sanitize the identifier before embedding it in the CEL expression.
-
Receive broadened credentials. Polaris constructs the CAB with the injected CEL condition and returns delegated GCS credentials. Because the CEL path restriction has been collapsed by the injection, these credentials are effectively scoped to the entire configured bucket rather than a single table prefix.
-
Operate across the bucket. The attacker uses the returned credentials to perform operations against any prefix in the bucket.
Confirmed Impact on Polaris 1.4.0 with Real GCS
Private testing against Polaris 1.4.0 on real Google Cloud Storage confirmed the full extent of the collapse. The delegated credentials could perform the following operations across the attacker's own table prefix, other tables' prefixes, and entirely unrelated external prefixes within the same bucket:
| Operation | Own Table Prefix | Other Table Prefix | Unrelated External Prefix |
|---|---|---|---|
| List objects | Permitted | Permitted | Permitted |
| Read metadata JSON | Permitted | Permitted | Permitted |
| Create object | Permitted | Permitted | Permitted |
| Delete object | Permitted | Permitted | Permitted |
This is a complete collapse of tenant isolation within the bucket boundary. The issue is not limited to accessing "another table." Once Polaris returns credentials for the crafted table, the path restriction inside the configured bucket is effectively gone.
The testing used a Polaris principal with broad catalog privileges for setup. A separate least privilege Polaris RBAC variant has not yet been tested on GCS. However, the storage credential broadening behavior operates at the GCS CAB layer, after Polaris has already decided to issue credentials, so the core flaw is independent of Polaris level RBAC configuration.
Affected Systems and Versions
Apache Polaris versions prior to 1.4.1 are affected. The vulnerability was specifically confirmed on Polaris 1.4.0 running against Google Cloud Storage.
While the confirmed exploit targets GCS Credential Access Boundary conditions, the 1.4.1 release notes indicate improvements to storage URI handling for S3 as well. Organizations running Polaris with any storage backend on versions before 1.4.1 should treat their deployments as potentially affected.
The fix is included in Apache Polaris version 1.4.1, released on May 1, 2026.
