CVE-2026-42810: Apache Polaris has an Improper Input Validation Issue

Should you act?

Critical, preconditions apply

Severe if exploited, but exploitation needs conditions that may not apply to you. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• No confirmed exploitation. It is not in CISA’s KEV catalog and CISA’s SSVC assessment records no known exploitation. That can change quickly after a public write-up; re-check if you are affected.
• EPSS 0.7%, percentile 52: FIRST’s model estimates a 0.7% chance of exploitation activity in the next 30 days, higher than 52% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
• Needs an account (low (any account)). Exposure depends on who can log in.
• Only applies if your dependency tree includes org.apache.polaris:polaris-core (Maven) < 1.4.1, fixed in 1.4.1. Check your lockfile, including transitive dependencies.

What it is

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

From the GitHub advisory

Apache Polaris accepts literal characters in namespace and table names. When it later builds temporary S3 access policies for delegated table access, those same characters appear to be reused unescaped in S3 IAM resource patterns and s3:prefix conditions.

In S3 IAM policy matching, is treated as a wildcard rather than as ordinary text. That means temporary credentials issued for one crafted table can match the storage path of a different table.

In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary-credential path on both MinIO and real AWS S3, 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 ([table prefix]); - and, when write delegation was returned for the crafted table, creating and deleting an object under another table's exact S3 table prefix.

A control case using ordinary different names did not allow the same cross-table access.

Weakness type: CWE-116, CWE-20.

Product: org.apache.polaris:polaris-core (Maven) · Assigned by: apache · Published: 2026-05-04

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Attack requirements: none
• Privileges required: low (any account)
• User interaction: none

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation none, automatable no, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.69% probability of exploitation activity in the next 30 days; percentile 52.

Timeline

• 2026-05-04 — CVE record last updated
• 2026-05-04 — CVE record published by apache
• 2026-05-04 — GitHub-reviewed advisory GHSA-vxgg-mqx2-3w59 published (critical)

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vendor and project advisories, patches

1. lists.apache.org lists.apache.org

Vulnerability records

1. GitHub Advisory GHSA-vxgg-mqx2-3w59 github.com
2. CVE.org record CVE-2026-42810 cve.org
3. NVD entry CVE-2026-42810 nvd.nist.gov

Other references from the CVE record and advisory

1. openwall.com openwall.com
2. github.com github.com

Critical Maven advisories · Today’s Security Digest