TL;DR. Between May and August 2026, Apache Polaris, the Iceberg REST catalog donated by Snowflake, published four security advisories and shipped two additional quiet fixes that are all the same bug in different clothes: strings the client controls, table names, namespaces, storage paths, flowing into the computation of cloud credentials without being re-validated. The worst of them, CVE-2026-42811, let a single quote inside a table identifier break out of a GCS Credential Access Boundary expression and mint credentials that worked bucket-wide. None of this is a reason to avoid Polaris, which patched fast and is hardening visibly. It is a reason to update your threat model: a credential-vending catalog is not a metadata service with a security feature. It is a credential authority whose policy language is file paths, and every parser bug in it is an IAM bug.
On August 6, 2026, the Apache Polaris project published CVE-2026-64640: the Iceberg REST register endpoints read a caller-supplied metadata file using the catalog's own storage credentials before checking that the file sat inside the catalog's allowed storage locations. Severity: moderate, information disclosure only, fixed in 1.7.0. On its own it would not be worth a post. As the fourth entry in a four-month pattern, it is, because the pattern says something about where the lakehouse just moved its security boundary.
The catalog stopped being a bystander
For most of its history the data catalog was a bystander to access control. It described tables; engines and storage enforced who could read them. The Iceberg REST catalog protocol ended that separation with credential vending. When a client loads a table from Apache Polaris, the catalog does not just return metadata pointers. It computes the table's storage location, asks the cloud provider for a short-lived credential scoped to that location, and hands the credential to the client, which then reads and writes data files directly against object storage.
The scoping mechanics differ by cloud. On AWS, the catalog calls STS and attaches a session policy restricting the token to the table's S3 prefix. On Google Cloud, it requests a downscoped token whose Credential Access Boundary carries a CEL expression, a small condition language program, that encodes which object paths the token may touch. Either way, the credential's blast radius is defined by a string: the table's path, which is itself derived from names the client chose.
This is a genuinely good architecture. It removes long-lived bucket keys from every query engine, it gives each engine only the slice of storage it needs, and it puts one component in charge of the mapping from identity to storage access. We made a version of this argument for operational databases in our piece on ephemeral credentials for AI agents: short-lived, narrowly scoped credentials are the right direction. But the same move that makes the catalog useful makes it critical: the catalog is now the component that turns strings into IAM. The 2026 advisory record is what it looks like when that component's string handling lags its new responsibilities.
Four months of the same bug
The pattern is visible only when the advisories are laid side by side.
May 4, 2026, three critical advisories, all fixed in 1.4.1. CVE-2026-42809 (CVSS v4 9.4): during staged table creation, Polaris could "issue broad temporary ('vended') storage credentials ... before the effective table location has been validated or durably reserved", with write.data.path and write.metadata.path overrides steering where those credentials pointed. CVE-2026-42811 (9.4): the CEL condition inside a GCS Credential Access Boundary embedded table paths derived from namespace and table identifiers without escaping, so "a namespace or table identifier containing a single quote and other URI-safe CEL fragments can break out of the intended quoted string and change the meaning of the CEL condition." The project's own testing confirmed that credentials for one crafted table could create, read, delete, and list objects effectively bucket-wide. CVE-2026-42812 (9.4): "Polaris skips its intended location checks before performing a security-sensitive metadata write when only write.metadata.path changes", so an ALTER TABLE touching nothing but that one property could aim metadata writes, and the credentials later vended against them, at other tables' locations.
August 2, 2026, release 1.7.0. No CVE numbers, but the release notes carry two fixes in the same family: "Fix native catalog credential vending skipping allowedLocations re-validation" and "Fix GCS downscoped credential prefix boundary for locations without trailing slash." The second is the classic prefix bug: a scope for path /sales that also matches /sales_restricted because nothing pinned the boundary at the slash.
August 6, 2026, CVE-2026-64640, fixed in 1.7.0. The register endpoints, which adopt an existing Iceberg table into the catalog by pointing at its metadata file, read that caller-supplied path with the catalog's storage credentials before validating it against allowedLocations. Moderate severity, confidentiality only, and the fix arrived alongside new location validation flags. Notable less for its impact than for its shape: it is the third distinct code path in four months where a client-supplied location was trusted before being checked.
Six instances, one class. Every one of them is a string the client influences, a table name, a namespace, a property, a metadata path, participating in a security decision before validation, or escaping, or re-validation caught up with it.
The path is the policy. Whatever can influence the path, table names, table properties, registration pointers, influences the credential.
Escaping bugs are now IAM bugs
Strip the lakehouse vocabulary away and CVE-2026-42811 is SQL injection's younger sibling: attacker-controlled string, interpolated into a small program, without escaping. Every engineer knows that bug. What changed is the blast radius. When the interpolation target was a SQL query, the damage was bounded by the database user's grants. Here the interpolation target is the policy language of a cloud IAM system, and the output is a capability: a bearer token whose scope is whatever the mangled expression says it is.
That is the real content of the phrase credential vending, and it deserves to be said plainly: in a vending architecture, paths and names are no longer data. They are policy source code. The catalog compiles them into credentials. A parser gap between what the catalog thinks a path means and what the cloud provider's condition evaluator thinks it means is not a correctness bug with security implications. It is the whole security model.
The May and August advisories also rhyme with a failure mode we have written about in a different setting. CVE-2026-42812 is a time-of-check problem: the location was validated when the table was created, and the system assumed the validation still held after a later change to a single property. Stale authorization in agent pipelines has the same anatomy: a check performed at request time, silently invalidated by state change before use time. The fix Polaris shipped, re-validating at the security-sensitive moment rather than trusting an earlier check, is the same fix that stateful agent governance needs. It is apparently a lesson every credential-issuing system gets to learn once.
The principal with registration privileges is increasingly an agent
Every advisory in the class shares an attacker model: "an authenticated principal with permission to create or register tables." Five years ago that principal was a data engineer, and the honest reading of these CVEs would have been insider risk, real but bounded.
That reading is expiring. The privileges these advisories assume, create a table, alter a property, register a metadata location, are exactly the privileges being handed to automation. Ingestion frameworks register tables. Compaction services rewrite metadata. And increasingly, agentic pipelines do both: the pitch behind Databricks folding Lakebase and governance into one agent-native platform is precisely that agents will administer tables, not just query them. An agent that can be prompt-injected into issuing an ALTER TABLE is, from the catalog's point of view, an authenticated principal exercising a granted privilege. The CVE class is what that privilege was worth before the patches.
This is also where the catalog category's own trajectory raises the stakes. Catalogs are repositioning as the layer agents consult at runtime, a shift we covered in OpenMetadata's context layer rebrand. The more the catalog becomes the thing agents talk to, the more its endpoints sit on the direct path from model output to infrastructure effect. Polaris 1.7.0's addition of GCS principal attribution on vended credentials, stamping which principal a credential was minted for via Workload Identity Federation, is the right kind of response: when the requester might be an agent, per-principal attribution on every minted credential is the difference between an audit trail and a shrug.
If you run a REST catalog
The concrete guidance is short.
Upgrade. All four advisories are fixed: 1.4.1 closed the May batch, 1.7.0 closed the register endpoint issue and the two vending re-validation gaps. If you are on anything before 1.4.1, credential vending against GCS should be treated as compromised until you move.
Scope the catalog's own identity. The vended credential is downscoped from what the catalog's service account can reach, and CVE-2026-64640's impact was bounded by exactly that: the register endpoint could only disclose what the catalog's credentials could read. Give the catalog IAM permissions on the specific prefixes it manages, nothing wider, so that a future scoping bug degrades to a smaller failure.
Treat identifier hygiene as an attack surface. Post-disclosure analyses recommended rejecting quote characters and non-URI-safe bytes in namespace and table identifiers at an upstream gateway. That is defense in depth, not a fix, but it is cheap, and it acknowledges the real lesson: anything that flows into path construction is input to a policy compiler.
Audit who holds create, alter, and register privileges, including every service account and agent framework. In a vending architecture those are not modeling permissions. They are the ability to influence credential minting, and they should be reviewed with the same seriousness as IAM role grants, because that is functionally what they are.
Model the catalog as a credential authority: a component in the same trust class as your identity provider, whose compromise or confusion mints capabilities against your storage. That single reframing makes most of the right operational decisions, on isolation, on patching cadence, on who gets admin, fall out on their own.
Where Datapace sits
The 2026 Polaris record supports a thesis we keep arriving at from different directions: as AI and automation reach the data estate, the metadata layer stops describing access and starts granting it, and it has to be engineered to the standard that implies. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. Which principals can exercise which privileges, and what those privileges are actually worth downstream, is exactly the material that layer has to hold. If you are working through what governed agent access to your data infrastructure should look like, book a call.
Sources
- GitHub Advisory Database, CVE-2026-42809, Apache Polaris vended credentials during staged create, CVSS v4 9.4, published May 4, 2026.
- GitHub Advisory Database, CVE-2026-42811, CEL injection in GCS Credential Access Boundary expressions, CVSS v4 9.4, published May 4, 2026.
- GitHub Advisory Database, CVE-2026-42812, location checks skipped on write.metadata.path change, CVSS v4 9.4, published May 4, 2026.
- GitHub Advisory Database, CVE-2026-64640, register endpoints read caller-supplied metadata paths before validation, moderate, published August 6, 2026.
- Apache Polaris, releases: 1.4.1 (May 2026), 1.6.0 (July 9, 2026), 1.7.0 (August 2, 2026), including "Fix native catalog credential vending skipping allowedLocations re-validation", "Fix GCS downscoped credential prefix boundary for locations without trailing slash", and "Add GCS principal attribution to vended credentials via Workload Identity Federation".
- Apache Polaris, project repository.
- Alex Merced, Apache Data Lakehouse Weekly, August 10 to 18, 2026, coverage of the CVE-2026-64640 disclosure and Polaris 1.7.0 hardening.