Loading story…
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.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
Testing against Polaris 1.4.0 on real Google Cloud Storage confirmed that a crafted identifier could collapse path restrictions in delegated credentials. The returned credentials allowed listing, reading, creating, and deleting objects under other table prefixes and unrelated external prefixes in the same bucket.
Apache disclosed CVE-2026-42811, an important-severity vulnerability in Apache Polaris before version 1.4.1 involving Google Cloud Storage downscoped credentials. Crafted namespace or table identifiers could break the intended CEL-based restriction and broaden temporary credentials to effectively bucket-wide access within the configured bucket.
Apache disclosed CVE-2026-42809, an important-severity flaw in Apache Polaris before version 1.4.1. An authenticated low-privileged user could abuse staged table creation to obtain broad temporary storage credentials for an attacker-chosen location before Polaris validates or reserves it.
Apache states that vulnerabilities affecting Apache Polaris versions before 1.4.1 were fixed in release 1.4.1. The fixes address improper temporary storage credential scoping issues, including staged table creation abuse and GCS access-boundary manipulation.
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 sourceseclists.org
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 **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 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**.
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