Loading story…
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.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
Apache released HTTP Server version 2.4.67 to remediate CVE-2026-33523, with the fix tracked in the 2.4.x branch as revision r1933360. This addressed the response splitting issue in affected modules present in versions 2.4.0 through 2.4.66.
Apache disclosed CVE-2026-42812, an important-severity vulnerability in Apache Polaris before version 1.4.1 involving insufficient validation of the `write.metadata.path` table property. The flaw can let metadata be written to attacker-chosen storage locations and, in some configurations, expose temporary cloud-storage credentials for broader storage paths.
Apache recorded CVE-2026-33523, a low-severity HTTP response splitting flaw affecting Apache HTTP Server 2.4.0 through 2.4.66 when forwarding a malicious status line from untrusted or compromised backend servers. The issue was reported on 2026-03-05, and Apache credited Haruki Oyama of Waseda University, Merih Mengisteab, and Dawit Jeong with finding it.
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-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
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 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