Critical (9.9)

Apache Polaris leaks S3 cross-table data (CVE-2026-42810)

CVE-2026-42810

CVE-2026-42810: Apache Polaris 1.4.0 wildcard injection in table names leaks S3 access to other tables (CVSS 9.9). Update when vendor releases patch.

Patch now - CVE-2026-42810 is a critical wildcard injection in Apache Polaris 1.4.0 that lets low-privilege users access any table’s S3 data. No vendor patch available yet; apply mitigations below.

Overview

Apache Polaris (2024 release, version 1.4.0 affected) accepts literal * characters in namespace and table names. When Polaris builds temporary S3 access policies for delegated table access, these unescaped characters are reused in S3 IAM resource patterns and s3:prefix conditions. In S3 IAM policy matching, * is treated as a wildcard rather than ordinary text, meaning temporary credentials issued for one crafted table can match the storage path of a different table.

Private testing confirmed that credentials returned for crafted tables such as f*.t1, f*.*, *.*, and foo.* could reach other tables’ S3 locations. The confirmed behavior includes reading another table’s metadata control file (Iceberg metadata JSON), listing another table’s exact S3 table prefix, and, when write delegation was returned, creating and deleting objects under another table’s exact S3 table prefix. A least-privilege AWS S3 variant was also confirmed in which the attacker principal had only TABLE_CREATE and TABLE_WRITE_DATA on * - direct Polaris access to the victim table was forbidden, but the attacker could still create and load *.*, receive delegated S3 credentials, and use those S3 credentials to list, read, create, and delete objects under the victim table’s prefix.

Impact

This vulnerability allows an attacker with minimal Polaris permissions (namespace-scoped TABLE_CREATE and TABLE_WRITE_DATA on *) to:

  • Read any table’s Iceberg metadata JSON file, which reveals all data file locations and snapshot history
  • List and read data objects under any table’s S3 prefix
  • When write delegation is enabled, create and delete objects under any table’s S3 prefix

The ability to read and write to the Iceberg metadata JSON file is particularly dangerous - it is the control file that tells readers which data files belong to the table, making this a meaningful confidentiality and integrity problem. The CVSS 9.9 score reflects the low attack complexity and high impact.

Remediation and Mitigation

  • Patch: No vendor patch has been released as of this advisory. Watch the Apache Polaris downloads page for an update.
  • Mitigation: Disable wildcard characters (*) in namespace and table names at the application layer before they reach Polaris. Validate all table names against a regex that rejects asterisks.
  • Alternative: If S3 delegation is not required, disable the S3 temporary-credential feature entirely to eliminate the attack path.
  • Monitor: Audit S3 access logs for unexpected access patterns involving wildcard-prefixed table names.

Security Insight

This vulnerability is a textbook example of the danger of injecting user-controlled values into security policy languages without proper escaping. S3 IAM policies treat * as a wildcard matcher, but Polaris did not sanitize or escape asterisk characters in table names before using them in policy templates. This mirrors similar issues in other cloud permission systems where user input is reused in policy strings - such as when Azure RBAC role names contained evaluated expressions. The broader lesson is that any system that builds access control policies from user-supplied strings must carefully validate and escape special characters, especially when those policies are evaluated by an external service like AWS IAM.

Further Reading

Share:

Never miss a critical vulnerability

Get real-time security alerts delivered to your preferred platform.

Related Advisories

Never Miss a Critical Alert

CVE advisories, breach reports, and threat intel — delivered daily to your inbox.