CVE-2026-42810

*** Pendiente de traducción *** Apache Polaris accepts literal `*` characters in namespace and table names. When it<br /> later builds temporary S3 access policies for delegated table access, those<br /> same characters appear to be reused unescaped in S3 IAM resource patterns<br /> and<br /> `s3:prefix` conditions.<br /> <br /> <br /> <br /> In S3 IAM policy matching, `*` is treated as a wildcard rather than as<br /> ordinary text. That means temporary credentials issued for one crafted table<br /> can match the storage path of a different table.<br /> <br /> <br /> <br /> In private testing against Polaris 1.4.0 using Polaris&amp;#39; AWS S3 temporary-<br /> credential path on both MinIO and real AWS S3, credentials returned for<br /> crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other<br /> tables&amp;#39; S3 locations.<br /> <br /> <br /> The confirmed behavior includes:<br /> <br /> <br /> - reading another table&amp;#39;s metadata control file ([Iceberg metadata JSON]);<br /> <br /> - listing another table&amp;#39;s exact S3 table prefix ([table prefix]);<br /> <br /> - and, when write delegation was returned for the crafted table, creating<br /> and<br /> deleting an object under another table&amp;#39;s exact S3 table prefix.<br /> <br /> <br /> <br /> A control case using ordinary different names did not allow the same<br /> cross-table access.<br /> <br /> <br /> <br /> A least-privilege AWS S3 variant was also confirmed in which the attacker<br /> principal had no Polaris permissions on the victim table and only the<br /> minimal permissions required to create and use a crafted wildcard table<br /> (namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that<br /> setup, direct Polaris access to `foo.t1` remained forbidden, but the<br /> attacker<br /> could still create and load `*.*`, receive delegated S3 credentials, and use<br /> those credentials to list, read, create, and delete objects under `foo.t1`.<br /> <br /> <br /> <br /> In Iceberg, the metadata JSON file is a control file: it tells readers which<br /> data files belong to the table, which snapshots exist, and which table<br /> version<br /> to read. So unauthorized access to it is already a meaningful<br /> confidentiality<br /> problem. The confirmed write-capable variant means the issue is not limited<br /> to<br /> disclosure.