dbcve.org
PolarisApplication · Apache

CVE-2026-42811

CRITICAL · 9.9 CVSS v3.1 Published 2026-05-04
Fix available
A fix is available. Upgrade to 1.4.1 or later.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials that only work for one table's files, but a crafted namespace or table name can cause those credentials to work across the configured bucket instead. Apache Polaris builds Google Cloud Storage downscoped credentials by creating a Credential Access Boundary (CAB) with CEL conditions that are intended to restrict access to the requested table's storage path. The relevant CEL string is built from the bucket name and the table path. That table path is derived from namespace and table identifiers. In current code, that path appears to be inserted into the CEL expression without escaping. As a result, 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. In private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated GCS credentials whose CEL path restriction had effectively collapsed. Those delegated credentials could then: - list another table's object prefix; - read another table's metadata control file (Iceberg metadata JSON); - create and delete an object under another table's object prefix; - and also list, read, create, and delete objects under an unrelated external prefix in the same bucket that was not part of any table path. That last point is important. The issue is not limited to "another table". In the confirmed setup, once Apache Polaris returned credentials for the crafted table, the path restriction inside the configured bucket was effectively gone. The practical effect is that temporary credentials for one crafted table can be broader than the table Polaris was asked to authorize, and can become effectively bucket-wide within the configured bucket. The current GCS testing used a Polaris principal with broad catalog privileges for setup. A separate least-privilege Polaris RBAC variant has not yet been tested on GCS. However, the storage-credential broadening behavior itself has been confirmed on GCS.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Apache Polaris builds GCS downscoped credentials using CEL conditions that restrict access to table storage paths. The namespace and table identifiers are inserted into the CEL expression without proper escaping, allowing a crafted identifier containing single quotes and CEL fragments to break out of the quoted string and collapse the path restriction, making credentials effectively bucket-wide.

MitigationUpgrade to a version with fixed CEL expression escaping, or implement input validation to reject namespace/table identifiers containing characters that could break out of CEL string literals.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
PolarisApplication
Affected:< 1.4.1

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify Apache Polaris version
    Check the installed Apache Polaris version by reviewing the deployed JAR/WAR files, container image tags, or package manager records. Compare against the version 1.4.1 threshold.
    Affected if The installed version is any release prior to 1.4.1 (e.g., 1.4.0, 1.3.x, 1.2.x, etc.)
  2. Confirm GCS downscoped credentials feature is in use
    Review Polaris configuration for Google Cloud Storage integration settings. Look for configurations related to downscoped credentials, GCS storage backends, or cloud storage path definitions in the Polaris metadata catalog settings.
    Affected if GCS integration is enabled and Polaris is configured to build downscoped credentials for GCS storage access.
  3. Inspect namespace naming conventions
    Query the Polaris metadata catalog to list all namespace names defined in the system. Examine each namespace identifier for the presence of single quote characters (') or patterns that could be interpreted as CEL syntax fragments.
    Affected if Any namespace name contains a single quote character or contains text that could function as a CEL expression fragment when inserted into a quoted string context.
  4. Inspect table naming conventions within namespaces
    Query the Polaris metadata catalog to list all table names across all namespaces. Examine each table identifier for the presence of single quote characters (') or CEL-like syntax patterns.
    Affected if Any table name contains a single quote character or contains text that could function as a CEL expression fragment when inserted into a quoted string context.

A user is affected if running Apache Polaris version prior to 1.4.1 with GCS downscoped credentials enabled, and any namespace or table identifier contains characters (such as single quotes) or patterns capable of breaking out of the CEL string literal context.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 1.4.1 or later
Fixed in 1.4.1
Interim mitigation

Upgrade to a version with fixed CEL expression escaping, or implement input validation to reject namespace/table identifiers containing characters that could break out of CEL string literals.

Recommended fix High confidence

Apache Polaris 1.4.1

  1. 1. Identify the current Apache Polaris version in use by checking the deployment configuration or running `polaris --version`
  2. 2. Stop the Apache Polaris service to prevent continued exposure during the upgrade
  3. 3. Back up the Polaris data directory and configuration files to preserve existing catalog data and settings
  4. 4. Upgrade Apache Polaris to version 1.4.1 or later by following the official upgrade documentation for your deployment method
  5. 5. Verify the upgrade was successful by checking the Polaris version after startup
  6. 6. Test that GSC downscoped credentials are correctly restricted to table-specific paths by creating a table with a normal name and confirming the CEL expression in the credential properly isolates access
  7. 7. Verify that the vulnerability is remediated by testing with a crafted namespace/table name containing single quotes and CEL syntax characters - credentials should be rejected or the CEL condition should remain properly bounded

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Polaris Scoped from the published advisory
  • Consultation6.0 h
  • Implementation12.0 h
  • Testing8.0 h
  • Review / QA4.0 h
30.0 hours of engineering $5,280
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $8,448.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-42811 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-42811 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data