Apache Polaris Hit With Four Critical (CVSS 9.9) Credential-Vending CVEs — 1.4.1 Patch Ships (May 4, 2026)

The Apache Software Foundation on May 4, 2026 disclosed four critical credential-vending vulnerabilities in Apache Polaris — the Iceberg REST catalog donated by Snowflake — all rated CVSS 9.9 and all patched by an emergency 1.4.1 release shipped three days earlier on May 1, 2026. Any organisation running a self-hosted Polaris catalog older than 1.4.1 is exposed and should upgrade now.

What Happened

The four CVEs — CVE-2026-42809, CVE-2026-42810, CVE-2026-42811 and CVE-2026-42812 — were reserved on April 30, first surfaced on the public oss-security mailing list on May 2, and formally published on May 4. All four sit in Polaris's credential-vending path, the mechanism that issues short-lived AWS or Google Cloud credentials so query engines like Apache Spark, Trino, Flink, Doris, Dremio and StarRocks can read and write Iceberg tables without long-lived bucket access keys. Each bug breaks the assumption that those credentials are scoped only to the table the caller is allowed to touch.

The 1.4.1 release notes summarise the fixes tersely as improvements to "storage uri handling in S3 + GCS," "locations-handling" and "staged table handling." The technical impact, as documented in the CVE records and follow-on advisories, is much sharper: an authenticated catalog user can be tricked into issuing storage credentials for paths and buckets the catalog never intended to expose.

Key Details

• CVE-2026-42809 — Staged table credential leak: Polaris vends storage credentials for staged-table creation before validating the user-supplied location, write.data.path and write.metadata.path. CVSS 4.0 vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H — 9.4 Critical.
• CVE-2026-42810 — S3 wildcard policy bypass: Table names containing literal * characters were re-used unescaped in IAM resource patterns and s3:prefix conditions, granting cross-table access on the same bucket.
• CVE-2026-42811 — GCS credential downscoping bypass: A crafted namespace or table name causes Polaris to issue Google Cloud Storage credentials with bucket-wide scope instead of the intended table-prefix scope.
• CVE-2026-42812 — Metadata-write bypass via ALTER: An authenticated user with table-settings permissions can set write.metadata.path to attacker-controlled storage; Polaris dutifully writes metadata there and vends credentials for that path.
• Affected versions: all releases prior to 1.4.1, including the 1.4.0 release dated April 21, 2026. Apache Polaris graduated from the ASF Incubator in February 2026, so virtually every production deployment is post-incubation.

What Developers and Users Are Saying

As of publication, the disclosure was still propagating from the oss-security mailing list and security feeds (TheHackerWire, ThreatINT) into broader developer forums — there were no high-volume Hacker News or Reddit threads dedicated to the four CVEs yet. Adjacent Iceberg-catalog discussion threads on Hacker News (the original Polaris launch and the recent Bingsan Show HN) characterise the credential-vending design as Polaris's most security-sensitive surface, which is exactly where the bugs landed. Security write-ups frame the failure mode bluntly, calling it a case where "scope limitation becomes attacker-directed" — Polaris was meant to constrain credentials, but the malformed inputs flipped that constraint into an attacker-chosen scope.

What This Means for Developers

Anyone running self-hosted Apache Polaris should upgrade to 1.4.1 immediately and rotate any IAM roles or service-account keys whose trust policies the catalog can assume. Pre-1.4.1 deployments may have written Iceberg metadata files and issued cloud-storage credentials to attacker-chosen S3 or GCS paths; incident responders should review CloudTrail and GCS audit logs for unexpected AssumeRole events, foreign bucket prefixes in metadata pointers, and unfamiliar table creations during the affected window. Customers of Snowflake Open Catalog, the managed Polaris service, should consult the Snowflake security advisory for the service-side patch timeline.

All four CVEs are network-reachable, and CVE-2026-42809's vector lists PR:L — only low privileges are required, which means anyone with permission to create a staged table on the catalog could exercise the bug.

What's Next

Apache Polaris 1.4.1 is the canonical fix and is published as source tar.gz, binary tgz and binary zip artifacts, plus Spark 3.5 client jars for Scala 2.12 and 2.13. The 1.4.x roadmap, outlined in Snowflake's Polaris 1.4 release engineering blog, prioritises further security controls and metrics — expect additional hardening releases through 2026. Downstream Iceberg client guidance and cloud-vendor advisories from AWS and Google are likely to follow as the disclosure circulates more widely.

Sources

• Apache Polaris 1.4.1 release page — primary vendor source confirming the patch and ship date.
• CVE-2026-42809 record — full advisory text and CVSS 4.0 vector.
• TheHackerWire — CVE-2026-42809 coverage.
• TheHackerWire — CVE-2026-42810 on the S3 wildcard bypass.
• TheHackerWire — CVE-2026-42812 on the ALTER-style metadata write bypass.
• Snowflake engineering blog — Apache Polaris 1.4 release for project context.
• oss-security mailing list disclosure thread dated May 2, 2026.