Loading story…
Apache Polaris disclosed two high-severity vulnerabilities that can cause the platform to vend overly broad temporary storage credentials, allowing low-privileged users to reach data outside their intended scope. In CVE-2026-42810, Polaris versions before 1.4.1 accept literal * characters in namespace and table names and then reuse them unescaped when building delegated AWS S3 access policies. Because S3 IAM treats * as a wildcard, credentials issued for crafted names such as f*.t1, f*.*, *.*, and foo.* were shown in testing to match other tables’ S3 paths on both AWS S3 and MinIO.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
A CVE listing published technical details for CVE-2026-42810, reiterating that crafted wildcard names such as 'f*.t1', 'f*.*', '*.*', and 'foo.*' could broaden delegated S3 credentials in Apache Polaris. It also highlighted a least-privilege scenario where an attacker without permission on the victim table could still access that table's objects via wildcard-crafted tables.
A CVE entry published details for CVE-2026-42809, describing how staged table creation in Apache Polaris could vend delegated storage credentials for attacker-controlled or unvalidated locations before proper validation and reservation. The entry noted low-privilege abuse paths, path override influence, and high-impact CVSS scoring.
A security advisory disclosed CVE-2026-42810 as an important-severity vulnerability in Apache Polaris before version 1.4.1. The flaw stems from accepting literal '*' characters in namespace and table names and reusing them unescaped in temporary S3 access policies, enabling unauthorized cross-table access and integrity impact.
Private testing against Apache Polaris 1.4.0 on MinIO and AWS S3 confirmed that wildcard-bearing namespace or table names could cause delegated S3 credentials to match other tables' storage paths. Observed impact included reading Iceberg metadata, listing another table's exact S3 prefix, and, with write delegation, creating and deleting objects under another table's prefix.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcecvefeed.io
Open sourceseclists.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Apache disclosed two important-severity vulnerabilities in **Apache Polaris** fixed in version **1.4.1** that can let an authenticated low-privileged user obtain overly broad temporary Google Cloud Storage credentials. In **`CVE-2026-42809`**, Polaris can vend delegated storage credentials during staged table creation *before* validating or reserving the requested location, allowing an attacker to supply a custom location and receive access for an attacker-chosen path. The staged-create flow also accepts `write.data.path` and `write.metadata.path` properties that can further influence the effective table location used for credential vending. In **`CVE-2026-42811`**, Polaris incorrectly builds Credential Access Boundary CEL conditions for downscoped GCS credentials by inserting namespace and table-derived paths without escaping. Apache said a crafted namespace or table identifier can break out of the intended quoted string and collapse the path restriction, causing credentials meant for one table to work across the configured bucket. Private testing against Polaris **1.4.0** on real GCS showed the returned credentials could list, read, create, and delete objects under other table prefixes and unrelated external prefixes in the same bucket, making the practical impact effectively bucket-wide access within that bucket.
Jun 29, 2026
Apache disclosed **CVE-2026-42812**, an important-severity vulnerability in Apache Polaris before **1.4.1** that fails to enforce validation on the `write.metadata.path` table property during certain ALTER TABLE-style updates. By changing only that property, a user can cause Polaris to write Apache Iceberg table metadata to an attacker-chosen reachable storage location instead of the intended validated path. In deployments where `polaris.config.allow.unstructured.table.location=true` and `allowedLocations` is broadly configured, the malicious path can be saved and later used by table-load and credential APIs to obtain temporary cloud-storage credentials for that same location without revalidation. Apache warned this can expose or enable modification, corruption, or deletion of data and metadata beyond the targeted table, potentially affecting other prefixes or even bucket or container roots depending on configuration and provider behavior; the underlying validation bypass still exists even when unstructured table locations are disabled, though later checks may prevent the unsafe path from being persisted.
Jun 29, 2026
Apache disclosed **CVE-2026-64640**, a low-severity vulnerability in `org.apache.polaris:polaris-runtime-service` affecting versions through **1.6.0**. The flaw occurs in the platform's table and view registration flow, where the register endpoint can read an attacker-controlled Iceberg metadata location before verifying that the object is within the catalog's configured allowed storage locations. Under specific conditions, an authenticated user with registration privileges could cause Polaris to perform a server-side read using the catalog's storage credentials, potentially exposing limited information from an object outside the intended storage boundary. Apache said the issue is relevant to deployments using **S3 credential vending** where the underlying storage credentials can access the out-of-bounds object, and reported impact is limited to **confidentiality**, with no demonstrated integrity or availability effects.
Aug 6, 2026