Wildcard in table names collapses S3 credential scope in Apache Polaris

TL;DR - Apache Polaris accepted literal * in namespace and table names, then reused those characters unescaped when constructing S3 IAM policy patterns. Because * is a wildcard in IAM, delegated credentials scoped to one crafted table can match a different table's S3 prefix entirely. Affected: Apache Polaris before 1.4.1.

What happened

Apache Polaris is an open-source Iceberg REST catalog that vends short-lived cloud storage credentials so query engines can read and write a table's underlying S3 objects without requiring broad bucket access.

CVE-2026-42810 is a policy-construction injection flaw in that credential-vending path. Polaris permits literal * characters in namespace and table names. When it later builds temporary S3 access policies, those same characters land unescaped inside IAM resource patterns and s3:prefix conditions. IAM treats * as a wildcard - not a literal character - so a credential ostensibly scoped to one crafted table can match a completely different table's storage path.

The reporter confirmed the issue on Polaris 1.4.0 against both MinIO and real AWS S3. Table names like f*.t1, *.*, and foo.* produced delegated credentials that could:

• read another table's Iceberg metadata JSON,
• list another table's exact S3 prefix,
• and, when write delegation was returned, create and delete objects under that prefix.

The least-privilege variant is worth paying attention to. An attacker doesn't need Polaris permission on the victim table. Having just enough permission to create and use the crafted wildcard table is enough to obtain credentials that work against the victim's prefix.

This is the recurring failure mode for credential-vending systems. Interpolate user-controlled identifiers into a policy language without escaping them, and your authorization boundary evaporates - no cryptography to break, no privilege to escalate through.

Who is impacted

• Deployments running Apache Polaris versions before 1.4.1.
• Environments using Polaris' AWS S3 temporary-credential delegation path.
• Highest risk: multi-tenant catalogs where less-trusted principals can create namespaces or tables, and where different tables represent different security boundaries.

What to do now

• Upgrade to Apache Polaris 1.4.1 or later - this is the fix.
• Audit for risky identifiers that already exist:
  • search namespaces and tables for any containing a literal *
  • treat those objects as suspect and evaluate renaming or removal under your change process
• Treat this as a delegated-credential scope failure, not just a naming quirk:
  • review where Polaris-issued temporary credentials are permitted to read or write in S3
  • check S3 access logs and any Polaris audit logs for cross-table prefix access that contradicts your Polaris RBAC configuration
• Reduce exposure in the meantime:
  • restrict who can create namespaces and tables in shared catalogs until patching is complete
  • avoid designs where a single bucket holds multiple tenants when isolation relies primarily on delegated credential scoping