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. It collapses the Credential Access Boundary that is meant to restrict temporary GCS tokens to a single Iceberg table's files, and the holder ends up with 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, and it recently graduated to an Apache Top-Level Project. Snowflake uses it as the interoperability layer for its Horizon Catalog. Fivetran uses it as the foundation of its Iceberg REST Catalog across S3, ADLS, GCS, and OneLake destinations. Because Polaris is shared infrastructure across major data platforms, a flaw in how it scopes credentials carries unusual weight.
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 builds a Google Cloud Storage Credential Access Boundary (CAB) that contains a Common Expression Language (CEL) condition. That condition is meant to restrict the resulting temporary credentials so they only work against the storage path of the requested table. Polaris builds the CEL string from two inputs: the bucket name and the table path. The table path comes from the namespace and table identifiers that the client supplies.
In versions prior to 1.4.1, Polaris inserts the table path into the CEL expression without escaping it. CEL delimits string literals with single quotes, so a namespace or table identifier that contains a single quote, followed by more URI-safe CEL syntax, can close the intended string literal early. The injected CEL fragments then become part of the expression logic itself, and they change the condition so that the path restriction is effectively removed.
Attack Flow
Exploitation takes four steps:
-
An attacker who can create namespaces or tables in a Polaris catalog creates a namespace or table name that contains a single quote and CEL fragments designed to neutralize the path condition.
-
The attacker sends 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.
-
Polaris builds the CAB with the injected CEL condition and returns delegated GCS credentials. The injection has collapsed the CEL path restriction, so these credentials are effectively scoped to the entire configured bucket rather than a single table prefix.
-
The attacker uses the returned credentials to operate 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 how far the collapse goes. The delegated credentials could perform the following operations on the attacker's own table prefix, on other tables' prefixes, and on 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 |
Tenant isolation within the bucket boundary collapses completely. Once Polaris returns credentials for the crafted table, the path restriction inside the configured bucket is effectively gone, so the exposure reaches well past "another table."
The test setup used a Polaris principal with broad catalog privileges. A separate least-privilege Polaris RBAC variant has not yet been tested on GCS. The credential broadening, though, happens 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.
The confirmed exploit targets GCS Credential Access Boundary conditions, but the 1.4.1 release notes also mention improvements to storage URI handling for S3. 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.
