CVE-2026-42811

*** Pendiente de traducción *** In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials<br /> that<br /> only work for one table&amp;#39;s files, but a crafted namespace or table name can<br /> cause those credentials to work across the configured bucket instead.<br /> <br /> <br /> Apache Polaris builds Google Cloud Storage downscoped credentials by creating a<br /> Credential Access Boundary (CAB) with CEL conditions that are intended to<br /> restrict access to the requested table&amp;#39;s storage path.<br /> <br /> <br /> <br /> The relevant CEL string is built from the bucket name and the table path.<br /> That<br /> table path is derived from namespace and table identifiers. In current code,<br /> that path appears to be inserted into the CEL expression without escaping.<br /> <br /> <br /> <br /> As a result, a namespace or table identifier containing a single quote and<br /> other URI-safe CEL fragments can break out of the intended quoted string and<br /> change the meaning of the CEL condition.<br /> <br /> <br /> <br /> In private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated<br /> GCS<br /> credentials whose CEL path restriction had effectively collapsed.<br /> <br /> <br /> Those delegated credentials could then:<br /> <br /> <br /> - list another table&amp;#39;s object prefix;<br /> <br /> - read another table&amp;#39;s metadata control file (Iceberg metadata JSON);<br /> <br /> - create and delete an object under another table&amp;#39;s object prefix;<br /> <br /> - and also list, read, create, and delete objects under an unrelated<br /> external<br /> prefix in the same bucket that was not part of any table path.<br /> <br /> <br /> <br /> That last point is important. The issue is not limited to "another table".<br /> In<br /> the confirmed setup, once Apache Polaris returned credentials for the crafted<br /> table,<br /> the path restriction inside the configured bucket was effectively gone.<br /> <br /> The practical effect is that temporary credentials for one crafted table<br /> can be<br /> broader than the table Polaris was asked to authorize, and can become<br /> effectively bucket-wide within the configured bucket.<br /> <br /> <br /> <br /> The current GCS testing used a Polaris principal with broad catalog<br /> privileges for setup. A separate least-privilege Polaris RBAC variant<br /> has not yet been tested on GCS. However, the storage-credential<br /> broadening behavior itself has been confirmed on GCS.