Vulnerabilities in pkg:maven/org.apache.polaris/polaris-runtime-service

PACKAGE
Advisory Identifier: GHSA-w76p-3cgp-qfcm
Advisory Summary

CVE-2026-42812 is a CRITICAL (CVSS 9.9) apache polaris has an improper vulnerability (CWE-20: Improper Input Validation) affecting Polaris runtime service libraries in the Maven ecosystem. The issue involves apache polaris has an improper input validation issue. Remediation is available by upgrading affected packages to version 1.4.1.

2 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:maven/org.apache.polaris/polaris-runtime-service

2 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:maven/org.apache.polaris/polaris-runtime-service. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-w76p-3cgp-qfcm CVE-2026-42812 CRITICAL Apache Polaris has an Improper Input Validation issue
GHSA-8ggj-j522-h5qf CVE-2026-42809 CRITICAL Apache Polaris has an Improper Input Validation Issue

CVE-2026-42812 at a Glance

CVE Identifier CVE-2026-42812
GHSA Identifier GHSA-w76p-3cgp-qfcm
Severity CRITICAL
CVSS v3.1 Base Score 9.9
CWE Classification CWE-20: Improper Input Validation
Affected Product Polaris runtime service
Package Ecosystem Maven
Published Date
Last Updated

Security Impact

CVSS: 9.9

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-42812

To remediate this vulnerability, upgrade all affected Polaris runtime service dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

org.apache.polaris:polaris-runtime-service fixed: 1.4.1
<dependency>
    <groupId>org.apache.polaris</groupId>
    <artifactId>polaris-runtime-service</artifactId>
    <version>1.4.1</version>
</dependency>
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

mvn dependency:tree -Dincludes=org.apache.polaris

How to Check if You Are Affected

To determine whether your Java application is affected by CVE-2026-42812, inspect your build dependencies using the Maven Dependency Plugin:

mvn dependency:tree -Dincludes=org.apache.polaris

Analyze the terminal output to locate any version of Polaris runtime service in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.4.1), your application is affected.

Note: The mvn dependency:tree -Dincludes=org.apache.polaris command inspects the resolved dependency graph declared in your project's POM files; it does not perform automated security scanning or inspect runtime dynamic classpaths. Always verify runtime container classpaths and shaded JARs.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-20: Improper Input Validation, where the product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. In Polaris runtime service, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

In Apache Iceberg, the table's metadata files are control files: they tell readers which data files belong to the table and which table version to read. `write.metadata.path` is an optional table property that tells Polaris where to write those metadata files. For a table already registered in a Polaris-managed catalog, changing only that property through an `ALTER TABLE`-style settings change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses the commit-time branch that is supposed to revalidate storage locations. The full persisted / credential-vending variant requires the affected catalog to have `polaris.config.allow.unstructured.table.location=true`, with `allowedLocations` broad enough to include the attacker-chosen target. `allowedLocations` is the admin-configured allowlist of storage paths that the catalog is allowed to use. Public project materials suggest that this flag is a real supported compatibility / layout mode, not just a contrived lab-only prerequisite. In that configuration, a user who can change table settings can cause Apache Polaris itself to write new table metadata to an attacker-chosen reachable storage location before the intended location-validation branch runs. If the later concrete-path validation also accepts that location, Polaris persists the resulting metadata path into stored table state. Later table-load and credential APIs can then return temporary cloud-storage credentials for the same location without revalidating it. In plain terms, Polaris can later hand out temporary storage access for the same attacker-chosen area. That attacker-chosen area does not need to be limited to the poisoned table's own files. If it is a broader storage prefix, another table's prefix, or, depending on configuration or provider behavior, even a bucket/container root, the resulting disclosure or corruption scope can extend to any data and metadata Polaris can reach there. The practical consequences are therefore similar to the staged-create credential-vending issue already discussed: data and metadata reachable in that storage scope can be exposed and, if write-capable credentials are later issued, modified, corrupted, or removed. Even before that later credential step, Polaris itself performs the metadata write to the unchecked location. So the core issue is not only later credential vending. The primary defect is that Polaris skips its intended location checks before performing a security-sensitive metadata write when only `write.metadata.path` changes. When `polaris.config.allow.unstructured.table.location=false`, current code review suggests the later `updateTableLike(...)` validation usually rejects out-of-tree metadata locations before the unsafe path is persisted. That may reduce the persisted / credential-vending variant, but it does not prevent the underlying defect: Polaris still skips the intended pre-write location check when only `write.metadata.path` changes.

CVE-2026-42812 Affected Polaris runtime service Versions

1 component(s)
Fixed Versions:
1.4.1
Product / Package Ecosystem Affected Versions Fixed Version
org.apache.polaris:polaris-runtime-service
Maven
≥ 0.9.0
< 1.4.1
1.4.1

References

Frequently Asked Questions

What is CVE-2026-42812?
CVE-2026-42812 is a security vulnerability in Polaris runtime service involving Apache Polaris has an Improper Input Validation issue under CWE-20: Improper Input Validation.
Which Polaris runtime service versions are affected?
Affected versions include releases prior to 1.4.1 across affected packages: org.apache.polaris:polaris-runtime-service.
What version fixes CVE-2026-42812?
Upgrading to 1.4.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is polaris-runtime-service affected?
Yes, org.apache.polaris:polaris-runtime-service is affected in releases prior to 1.4.1. Upgrade your dependency to 1.4.1 or later.
What is the CVSS score of CVE-2026-42812?
CVE-2026-42812 has a CVSS v3.1 base score of 9.9 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
What CWE is associated with CVE-2026-42812?
CVE-2026-42812 is classified under CWE-20: Improper Input Validation (The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.).
How can I check Maven dependencies for CVE-2026-42812?
Run the dependency tree command: 'mvn dependency:tree -Dincludes=org.apache.polaris'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-w76p-3cgp-qfcm",
  "modified" : "2026-08-31T22:49:07Z",
  "published" : "2026-05-04T18:30:31Z",
  "aliases" : [ "CVE-2026-42812" ],
  "summary" : "Apache Polaris has an Improper Input Validation issue",
  "details" : "In Apache Iceberg, the table's metadata files are control files: they tell readers which data files belong to the table and which table version to read.\n\n`write.metadata.path` is an optional table property that tells Polaris where to write those metadata files. For a table already registered in a Polaris-managed catalog, changing only that property through an `ALTER TABLE`-style settings change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses the commit-time branch that is supposed to revalidate storage locations.\n\nThe full persisted / credential-vending variant requires the affected catalog to have `polaris.config.allow.unstructured.table.location=true`, with `allowedLocations` broad enough to include the attacker-chosen target.\n\n`allowedLocations` is the admin-configured allowlist of storage paths that the catalog is allowed to use. Public project materials suggest that this flag is a real supported compatibility / layout mode, not just a contrived lab-only prerequisite.\n\nIn that configuration, a user who can change table settings can cause Apache Polaris itself to write new table metadata to an attacker-chosen reachable storage location before the intended location-validation branch runs.\n\nIf the later concrete-path validation also accepts that location, Polaris persists the resulting metadata path into stored table state. Later table-load and credential APIs can then return temporary cloud-storage credentials for the same location without revalidating it. In plain terms, Polaris can later hand out temporary storage access for the same attacker-chosen area.\n\nThat attacker-chosen area does not need to be limited to the poisoned table's own files. If it is a broader storage prefix, another table's prefix, or, depending on configuration or provider behavior, even a bucket/container root, the resulting disclosure or corruption scope can extend to any data and metadata Polaris can reach there.\n\nThe practical consequences are therefore similar to the staged-create credential-vending issue already discussed: data and metadata reachable in that storage scope can be exposed and, if write-capable credentials are later issued, modified, corrupted, or removed. Even before that later credential step, Polaris itself performs the metadata write to the unchecked location.\n\nSo the core issue is not only later credential vending. \n\nThe primary defect is that Polaris skips its intended location checks before performing a security-sensitive metadata write when only `write.metadata.path` changes.\n\nWhen `polaris.config.allow.unstructured.table.location=false`, current code review suggests the later `updateTableLike(...)` validation usually rejects out-of-tree metadata locations before the unsafe path is persisted. That may reduce the persisted / credential-vending variant, but it does not prevent the underlying defect: Polaris still skips the intended pre-write location check when only `write.metadata.path` changes.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
  }, {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Maven",
      "name" : "org.apache.polaris:polaris-runtime-service"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.9.0"
      }, {
        "fixed" : "1.4.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-42812"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/apache/polaris/commit/1cdac7b78c0aa6cc6cad4da10a442ae262d1aae3"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/apache/polaris/commit/d6bbcc386e61d08ba5df1f820d0724816d84427b"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/apache/polaris"
  }, {
    "type" : "WEB",
    "url" : "https://lists.apache.org/thread/wxd2wj3p0smvrk84msv317wg5tp3jtw9"
  }, {
    "type" : "WEB",
    "url" : "http://www.openwall.com/lists/oss-security/2026/05/02/13"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-20" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-08T18:18:20Z",
    "nvd_published_at" : "2026-05-04T17:16:26Z"
  }
}