CVE-2026-42810: Apache Polaris Information Disclosure

CVE-2026-42810 Overview

Apache Polaris accepts literal * characters in namespace and table names without sanitization. The application later reuses those characters unescaped when constructing temporary Amazon S3 access policies for delegated table access. Because S3 IAM policy matching treats * as a wildcard, temporary credentials issued for a crafted table can match the storage paths of unrelated tables.

The flaw is classified under [CWE-20] (Improper Input Validation) and was confirmed against Apache Polaris 1.4.0 on both MinIO and AWS S3 backends.

Critical Impact

Authenticated attackers with minimal namespace-scoped privileges can create wildcard-named tables, obtain delegated S3 credentials, and read, list, write, or delete objects belonging to other tables they have no Polaris authorization to access.

Affected Products

• Apache Polaris 1.4.0 (confirmed in private testing)
• Apache Polaris deployments using the AWS S3 temporary-credential delegation path
• Apache Polaris environments backed by MinIO or AWS S3 storage

Discovery Timeline

• 2026-05-04 - CVE-2026-42810 published to NVD
• 2026-05-05 - Last updated in NVD database

Technical Details for CVE-2026-42810

Vulnerability Analysis

Apache Polaris is an open-source catalog for Apache Iceberg tables that brokers access to underlying object storage through delegated, temporary credentials. The catalog accepts table and namespace identifiers containing literal * characters and propagates those identifiers into generated AWS Identity and Access Management (IAM) policy documents.

When Polaris constructs the IAM policy for a session token, the table name is interpolated into the Resource ARN and into s3:prefix condition values. AWS evaluates * in these positions as a wildcard rather than a literal character. A token issued for f*.t1, f*.*, *.*, or foo.* therefore matches the S3 prefix of any table whose path begins with the supplied stem.

Confirmed cross-table operations include reading another table's Iceberg metadata JSON control file, listing the victim table's exact S3 prefix, and creating or deleting objects under that prefix when write delegation is granted. The Iceberg metadata JSON identifies which data files, snapshots, and table version a reader will use, so unauthorized access constitutes both a confidentiality and integrity exposure.

Root Cause

The root cause is missing input validation on namespace and table identifiers combined with unescaped reuse of those identifiers in IAM policy construction. Polaris treats * as a normal character at the catalog layer but AWS S3 IAM treats it as a glob, producing a semantic mismatch that authorizes broader access than intended.

Attack Vector

A control case using ordinary distinct names did not allow cross-table access, demonstrating that wildcard injection is the required trigger. A least-privilege variant was confirmed in which the attacker principal held only namespace-scoped TABLE_CREATE and TABLE_WRITE_DATA on * and had no Polaris permissions on the victim table. Direct catalog access to foo.t1 remained forbidden, yet the attacker could create *.*, request delegated S3 credentials, and use those credentials out-of-band to enumerate and modify objects under foo.t1. The exploitation is fully network-reachable and requires only a low-privileged authenticated principal.

No proof-of-concept code has been published. See the Apache Mailing List Thread and the Openwall OSS Security Update for the full advisory text.

Detection Methods for CVE-2026-42810

Indicators of Compromise

• Polaris catalog entries containing * in namespace or table identifiers, including patterns such as *.*, foo.*, f*.t1, and f*.*.
• AWS CloudTrail or MinIO audit events showing s3:GetObject, s3:ListBucket, s3:PutObject, or s3:DeleteObject calls whose session credentials were issued for a table whose ARN contains *.
• Access patterns where a single short-lived session token interacts with multiple distinct table prefixes.

Detection Strategies

• Inspect Polaris catalog metadata for any namespace or table name containing * and treat such entries as suspicious until proven otherwise.
• Correlate Polaris loadTable and credential-vending events with subsequent S3 access logs to identify sessions where the requested table name and the accessed prefix do not match.
• Alert on any Iceberg metadata JSON read followed by writes to the same prefix from a session whose originating table identifier differs from the target prefix.

Monitoring Recommendations

• Forward Polaris audit logs and AWS CloudTrail S3 data events into a centralized analytics platform for cross-source correlation. The Singularity Data Lake supports OCSF normalization of cloud audit telemetry that enables this style of cross-table correlation.
• Monitor for least-privilege principals that suddenly issue delegated-credential requests against newly created tables with unusual identifier characters.
• Track the frequency of TABLE_CREATE operations on namespace-scoped wildcard grants and review any spikes.

How to Mitigate CVE-2026-42810

Immediate Actions Required

• Audit all Polaris namespaces and tables for identifiers containing * and remove or quarantine any unexpected entries.
• Restrict TABLE_CREATE and TABLE_WRITE_DATA privileges, particularly any wildcard (*) namespace grants, to trusted principals only.
• Rotate any AWS access keys or session credentials that may have been issued via the affected delegation path during the exposure window.
• Review S3 bucket access logs and CloudTrail history for unexplained cross-table access since the vulnerable version was deployed.

Patch Information

Review the Apache Mailing List Thread and Openwall OSS Security Update for the latest guidance from the Apache Polaris project on fixed releases. Upgrade to the patched version as soon as it is published by the vendor.

Workarounds

• Implement an admission control layer or proxy that rejects Polaris API requests whose namespace or table identifiers contain *, ?, or other IAM glob metacharacters.
• Tighten the IAM trust policy attached to Polaris's vending role so that issued session policies cannot grant access outside an explicitly enumerated set of prefixes.
• Disable the AWS S3 temporary-credential delegation path for untrusted principals until a fixed Polaris release is deployed.
• Apply S3 bucket policies that constrain s3:prefix values to a known allowlist of table paths, providing a defense-in-depth backstop against wildcard expansion.

# Example: reject Polaris table names containing IAM wildcard metacharacters
# at an API gateway or reverse proxy in front of Polaris
if echo "$TABLE_NAME$NAMESPACE" | grep -qE '[*?]'; then
  echo "Rejected: identifier contains wildcard metacharacter" >&2
  exit 1
fi