Search criteria
8 vulnerabilities found for Apache Polaris by Apache Software Foundation
CVE-2026-42812 (GCVE-0-2026-42812)
Vulnerability from nvd – Published: 2026-05-04 16:19 – Updated: 2026-05-04 16:38
VLAI?
Title
Apache Polaris: No protection on `write.metadata.path`
Summary
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.
Severity ?
9.9 (Critical)
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/wxd2wj3p0smvrk84m… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Polaris |
Affected:
0 , < 1.4.1
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42812",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-04T16:31:28.354079Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:31:33.619Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2026-05-04T16:38:57.660Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/13"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Polaris",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "1.4.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eIn Apache Iceberg, the table\u0027s metadata files are control files: they tell readers\nwhich data files belong to the table and which table version to read.\n\u003cbr\u003e\u003cbr\u003e\n`write.metadata.path` is an optional table property that tells Polaris\nwhere to\nwrite those metadata files. \u003cbr\u003eFor a table already registered in a\nPolaris-managed\ncatalog, changing only that property through an `ALTER TABLE`-style settings\nchange (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses\nthe commit-time branch that is supposed to revalidate storage locations.\n\nThe full persisted / credential-vending variant requires the affected\ncatalog\nto have `polaris.config.allow.unstructured.table.location=true`, with\n`allowedLocations` broad enough to include the attacker-chosen target.\n\u003cbr\u003e\u003cbr\u003e`allowedLocations` is the admin-configured allowlist of storage paths that\nthe\ncatalog is allowed to use. Public project materials suggest that this flag\nis a\nreal supported compatibility / layout mode, not just a contrived lab-only\nprerequisite.\n\u003cbr\u003e\nIn that configuration, a user who can change table settings can cause Apache Polaris\nitself to write new table metadata to an attacker-chosen reachable storage\nlocation before the intended location-validation branch runs.\n\nIf the later concrete-path validation also accepts that location, Polaris\npersists the resulting metadata path into stored table state. Later\ntable-load\nand credential APIs can then return temporary cloud-storage credentials for\nthe\nsame location without revalidating it. In plain terms, Polaris can later\nhand\nout temporary storage access for the same attacker-chosen area.\n\nThat attacker-chosen area does not need to be limited to the poisoned\ntable\u0027s\nown files. If it is a broader storage prefix, another table\u0027s prefix, or,\ndepending on configuration or provider behavior, even a bucket/container\nroot,\nthe resulting disclosure or corruption scope can extend to any data and\nmetadata Polaris can reach there.\n\u003cbr\u003e\u003cbr\u003e\nThe practical consequences are therefore similar to the staged-create\ncredential-vending issue already discussed: data and metadata reachable in\nthat\nstorage scope can be exposed and, if write-capable credentials are later\nissued, modified, corrupted, or removed. Even before that later credential\nstep, Polaris itself performs the metadata write to the unchecked location.\n\nSo the core issue is not only later credential vending. \u003cbr\u003e\u003cbr\u003eThe primary defect\nis\nthat Polaris skips its intended location checks before performing a\nsecurity-\nsensitive metadata write when only `write.metadata.path` changes.\n\u003cbr\u003e\u003cbr\u003e\nWhen `polaris.config.allow.unstructured.table.location=false`, current code\nreview suggests the later `updateTableLike(...)` validation usually rejects\nout-of-tree metadata locations before the unsafe path is persisted. That may\nreduce the persisted / credential-vending variant, but it does not prevent\nthe\nunderlying defect: Polaris still skips the intended pre-write location check\nwhen only `write.metadata.path` changes.\u003c/span\u003e\u003cbr\u003e"
}
],
"value": "In Apache Iceberg, the table\u0027s metadata files are control files: they tell readers\nwhich data files belong to the table and which table version to read.\n\n\n\n`write.metadata.path` is an optional table property that tells Polaris\nwhere to\nwrite those metadata files. \nFor a table already registered in a\nPolaris-managed\ncatalog, changing only that property through an `ALTER TABLE`-style settings\nchange (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses\nthe commit-time branch that is supposed to revalidate storage locations.\n\nThe full persisted / credential-vending variant requires the affected\ncatalog\nto have `polaris.config.allow.unstructured.table.location=true`, with\n`allowedLocations` broad enough to include the attacker-chosen target.\n\n\n`allowedLocations` is the admin-configured allowlist of storage paths that\nthe\ncatalog is allowed to use. Public project materials suggest that this flag\nis a\nreal supported compatibility / layout mode, not just a contrived lab-only\nprerequisite.\n\n\nIn that configuration, a user who can change table settings can cause Apache Polaris\nitself to write new table metadata to an attacker-chosen reachable storage\nlocation before the intended location-validation branch runs.\n\nIf the later concrete-path validation also accepts that location, Polaris\npersists the resulting metadata path into stored table state. Later\ntable-load\nand credential APIs can then return temporary cloud-storage credentials for\nthe\nsame location without revalidating it. In plain terms, Polaris can later\nhand\nout temporary storage access for the same attacker-chosen area.\n\nThat attacker-chosen area does not need to be limited to the poisoned\ntable\u0027s\nown files. If it is a broader storage prefix, another table\u0027s prefix, or,\ndepending on configuration or provider behavior, even a bucket/container\nroot,\nthe resulting disclosure or corruption scope can extend to any data and\nmetadata Polaris can reach there.\n\n\n\nThe practical consequences are therefore similar to the staged-create\ncredential-vending issue already discussed: data and metadata reachable in\nthat\nstorage scope can be exposed and, if write-capable credentials are later\nissued, modified, corrupted, or removed. Even before that later credential\nstep, 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\nis\nthat Polaris skips its intended location checks before performing a\nsecurity-\nsensitive metadata write when only `write.metadata.path` changes.\n\n\n\nWhen `polaris.config.allow.unstructured.table.location=false`, current code\nreview suggests the later `updateTableLike(...)` validation usually rejects\nout-of-tree metadata locations before the unsafe path is persisted. That may\nreduce the persisted / credential-vending variant, but it does not prevent\nthe\nunderlying defect: Polaris still skips the intended pre-write location check\nwhen only `write.metadata.path` changes."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-284",
"description": "CWE-284 Improper Access Control",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-732",
"description": "CWE-732 Incorrect Permission Assignment for Critical Resource",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:19:55.828Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/wxd2wj3p0smvrk84msv317wg5tp3jtw9"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Polaris: No protection on `write.metadata.path`",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-42812",
"datePublished": "2026-05-04T16:19:55.828Z",
"dateReserved": "2026-04-30T14:36:55.718Z",
"dateUpdated": "2026-05-04T16:38:57.660Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42811 (GCVE-0-2026-42811)
Vulnerability from nvd – Published: 2026-05-04 16:37 – Updated: 2026-05-04 19:48
VLAI?
Title
Apache Polaris: could broaden vended GCS credentials through unescaped identifier content in access-boundary CEL conditions
Summary
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.
Severity ?
9.9 (Critical)
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/hovn5hmkj9wj7v9cd… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Polaris |
Affected:
0 , < 1.4.1
(semver)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2026-05-04T16:38:55.378Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/12"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42811",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-04T19:48:24.896527Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T19:48:33.457Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Polaris",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "1.4.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eIn plain terms, Apache Polaris is supposed to issue short-lived GCS credentials\nthat\nonly work for one table\u0027s files, but a crafted namespace or table name can\ncause those credentials to work across the configured bucket instead.\n\u003cbr\u003e\u003cbr\u003eApache Polaris builds Google Cloud Storage downscoped credentials by creating a\nCredential Access Boundary (CAB) with CEL conditions that are intended to\nrestrict access to the requested table\u0027s storage path.\n\u003cbr\u003e\u003cbr\u003e\nThe relevant CEL string is built from the bucket name and the table path.\nThat\ntable path is derived from namespace and table identifiers. In current code,\nthat path appears to be inserted into the CEL expression without escaping.\n\u003cbr\u003e\u003cbr\u003e\nAs a result, a namespace or table identifier containing a single quote and\nother URI-safe CEL fragments can break out of the intended quoted string and\nchange the meaning of the CEL condition.\n\u003cbr\u003e\u003cbr\u003e\nIn private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated\nGCS\ncredentials whose CEL path restriction had effectively collapsed.\n\u003cbr\u003e\nThose delegated credentials could then:\n\u003cbr\u003e\n- list another table\u0027s object prefix;\n\u003cbr\u003e- read another table\u0027s metadata control file (Iceberg metadata JSON);\n\u003cbr\u003e- create and delete an object under another table\u0027s object prefix;\n\u003cbr\u003e- and also list, read, create, and delete objects under an unrelated\nexternal\nprefix in the same bucket that was not part of any table path.\n\u003cbr\u003e\u003cbr\u003e\nThat last point is important. The issue is not limited to \"another table\".\nIn\nthe confirmed setup, once Apache Polaris returned credentials for the crafted\ntable,\nthe path restriction inside the configured bucket was effectively gone.\n\nThe practical effect is that temporary credentials for one crafted table\ncan be\nbroader than the table Polaris was asked to authorize, and can become\neffectively bucket-wide within the configured bucket.\n\u003cbr\u003e\u003cbr\u003e\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eThe current GCS testing used a Polaris principal with broad catalog\nprivileges for setup. A separate least-privilege Polaris RBAC variant\nhas not yet been tested on GCS. However, the storage-credential\nbroadening behavior itself has been confirmed on GCS.\u003c/span\u003e\u003c/span\u003e\u003cbr\u003e"
}
],
"value": "In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials\nthat\nonly work for one table\u0027s files, but a crafted namespace or table name can\ncause those credentials to work across the configured bucket instead.\n\n\nApache Polaris builds Google Cloud Storage downscoped credentials by creating a\nCredential Access Boundary (CAB) with CEL conditions that are intended to\nrestrict access to the requested table\u0027s storage path.\n\n\n\nThe relevant CEL string is built from the bucket name and the table path.\nThat\ntable path is derived from namespace and table identifiers. In current code,\nthat path appears to be inserted into the CEL expression without escaping.\n\n\n\nAs a result, a namespace or table identifier containing a single quote and\nother URI-safe CEL fragments can break out of the intended quoted string and\nchange the meaning of the CEL condition.\n\n\n\nIn private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated\nGCS\ncredentials whose CEL path restriction had effectively collapsed.\n\n\nThose delegated credentials could then:\n\n\n- list another table\u0027s object prefix;\n\n- read another table\u0027s metadata control file (Iceberg metadata JSON);\n\n- create and delete an object under another table\u0027s object prefix;\n\n- and also list, read, create, and delete objects under an unrelated\nexternal\nprefix in the same bucket that was not part of any table path.\n\n\n\nThat last point is important. The issue is not limited to \"another table\".\nIn\nthe confirmed setup, once Apache Polaris returned credentials for the crafted\ntable,\nthe path restriction inside the configured bucket was effectively gone.\n\nThe practical effect is that temporary credentials for one crafted table\ncan be\nbroader than the table Polaris was asked to authorize, and can become\neffectively bucket-wide within the configured bucket.\n\n\n\nThe current GCS testing used a Polaris principal with broad catalog\nprivileges for setup. A separate least-privilege Polaris RBAC variant\nhas not yet been tested on GCS. However, the storage-credential\nbroadening behavior itself has been confirmed on GCS."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-917",
"description": "CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement (\u0027Expression Language Injection\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:37:02.030Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/hovn5hmkj9wj7v9cd8sn67svg03klgvg"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Polaris: could broaden vended GCS credentials through unescaped identifier content in access-boundary CEL conditions",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-42811",
"datePublished": "2026-05-04T16:37:02.030Z",
"dateReserved": "2026-04-30T14:30:15.047Z",
"dateUpdated": "2026-05-04T19:48:33.457Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42810 (GCVE-0-2026-42810)
Vulnerability from nvd – Published: 2026-05-04 16:48 – Updated: 2026-05-04 18:33
VLAI?
Title
Apache Polaris: could broaden vended S3 credentials through wildcard-bearing namespace or table names
Summary
Apache Polaris accepts literal `*` characters in namespace and table names. When it
later builds temporary S3 access policies for delegated table access, those
same characters appear to be reused unescaped in S3 IAM resource patterns
and
`s3:prefix` conditions.
In S3 IAM policy matching, `*` is treated as a wildcard rather than as
ordinary text. That means temporary credentials issued for one crafted table
can match the storage path of a different table.
In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary-
credential path on both MinIO and real AWS S3, credentials returned for
crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other
tables' S3 locations.
The confirmed behavior includes:
- reading another table's metadata control file ([Iceberg metadata JSON]);
- listing another table's exact S3 table prefix ([table prefix]);
- and, when write delegation was returned for the crafted table, creating
and
deleting an object under another table's exact S3 table prefix.
A control case using ordinary different names did not allow the same
cross-table access.
A least-privilege AWS S3 variant was also confirmed in which the attacker
principal had no Polaris permissions on the victim table and only the
minimal permissions required to create and use a crafted wildcard table
(namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that
setup, direct Polaris access to `foo.t1` remained forbidden, but the
attacker
could still create and load `*.*`, receive delegated S3 credentials, and use
those credentials to list, read, create, and delete objects under `foo.t1`.
In Iceberg, the metadata JSON file is a control file: it tells readers which
data files belong to the table, which snapshots exist, and which table
version
to read. So unauthorized access to it is already a meaningful
confidentiality
problem. The confirmed write-capable variant means the issue is not limited
to
disclosure.
Severity ?
9.9 (Critical)
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/gg3qq9sqg4hdjmprq… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Polaris |
Affected:
0 , < 1.4.1
(semver)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2026-05-04T17:37:04.202Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/11"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42810",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-04T18:32:53.859435Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T18:33:09.056Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Polaris",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "1.4.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eApache Polaris accepts literal `*` characters in namespace and table names. When it\nlater builds temporary S3 access policies for delegated table access, those\nsame characters appear to be reused unescaped in S3 IAM resource patterns\nand\n`s3:prefix` conditions.\n\u003cbr\u003e\u003cbr\u003e\nIn S3 IAM policy matching, `*` is treated as a wildcard rather than as\nordinary text. That means temporary credentials issued for one crafted table\ncan match the storage path of a different table.\n\u003cbr\u003e\u003cbr\u003e\nIn private testing against Polaris 1.4.0 using Polaris\u0027 AWS S3 temporary-\ncredential path on both MinIO and real AWS S3, credentials returned for\ncrafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other\ntables\u0027 S3 locations.\n\u003cbr\u003e\nThe confirmed behavior includes:\n\u003cbr\u003e\n- reading another table\u0027s metadata control file ([Iceberg metadata JSON]);\n\u003cbr\u003e- listing another table\u0027s exact S3 table prefix ([table prefix]);\n\u003cbr\u003e- and, when write delegation was returned for the crafted table, creating\nand\ndeleting an object under another table\u0027s exact S3 table prefix.\n\u003cbr\u003e\u003cbr\u003e\nA control case using ordinary different names did not allow the same\ncross-table access.\n\u003cbr\u003e\u003cbr\u003e\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eA least-privilege AWS S3 variant was also confirmed in which the attacker\nprincipal had no Polaris permissions on the victim table and only the\nminimal permissions required to create and use a crafted wildcard table\n(namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`).\u003c/span\u003e In that\nsetup, direct Polaris access to `foo.t1` remained forbidden, but the\nattacker\ncould still create and load `*.*`, receive delegated S3 credentials, and use\nthose credentials to list, read, create, and delete objects under `foo.t1`.\n\u003cbr\u003e\u003cbr\u003e\nIn Iceberg, the metadata JSON file is a control file: it tells readers which\ndata files belong to the table, which snapshots exist, and which table\nversion\nto read. So unauthorized access to it is already a meaningful\nconfidentiality\nproblem. The confirmed write-capable variant means the issue is not limited\nto\ndisclosure.\u003c/span\u003e\u003cbr\u003e"
}
],
"value": "Apache Polaris accepts literal `*` characters in namespace and table names. When it\nlater builds temporary S3 access policies for delegated table access, those\nsame characters appear to be reused unescaped in S3 IAM resource patterns\nand\n`s3:prefix` conditions.\n\n\n\nIn S3 IAM policy matching, `*` is treated as a wildcard rather than as\nordinary text. That means temporary credentials issued for one crafted table\ncan match the storage path of a different table.\n\n\n\nIn private testing against Polaris 1.4.0 using Polaris\u0027 AWS S3 temporary-\ncredential path on both MinIO and real AWS S3, credentials returned for\ncrafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other\ntables\u0027 S3 locations.\n\n\nThe confirmed behavior includes:\n\n\n- reading another table\u0027s metadata control file ([Iceberg metadata JSON]);\n\n- listing another table\u0027s exact S3 table prefix ([table prefix]);\n\n- and, when write delegation was returned for the crafted table, creating\nand\ndeleting an object under another table\u0027s exact S3 table prefix.\n\n\n\nA control case using ordinary different names did not allow the same\ncross-table access.\n\n\n\nA least-privilege AWS S3 variant was also confirmed in which the attacker\nprincipal had no Polaris permissions on the victim table and only the\nminimal permissions required to create and use a crafted wildcard table\n(namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that\nsetup, direct Polaris access to `foo.t1` remained forbidden, but the\nattacker\ncould still create and load `*.*`, receive delegated S3 credentials, and use\nthose credentials to list, read, create, and delete objects under `foo.t1`.\n\n\n\nIn Iceberg, the metadata JSON file is a control file: it tells readers which\ndata files belong to the table, which snapshots exist, and which table\nversion\nto read. So unauthorized access to it is already a meaningful\nconfidentiality\nproblem. The confirmed write-capable variant means the issue is not limited\nto\ndisclosure."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-116",
"description": "CWE-116 Improper Encoding or Escaping of Output",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:48:49.754Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/gg3qq9sqg4hdjmprqy46p40xmln61dm9"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Polaris: could broaden vended S3 credentials through wildcard-bearing namespace or table names",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-42810",
"datePublished": "2026-05-04T16:48:49.754Z",
"dateReserved": "2026-04-30T14:22:36.663Z",
"dateUpdated": "2026-05-04T18:33:09.056Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42809 (GCVE-0-2026-42809)
Vulnerability from nvd – Published: 2026-05-04 16:22 – Updated: 2026-05-04 16:38
VLAI?
Title
Apache Polaris: staged table creation could vend storage credentials for unvalidated locations
Summary
Apache Polaris can issue broad temporary ("vended") storage credentials during
staged
table creation before the effective table location has been validated or
durably reserved.
Those temporary credentials are meant to limit the scope
of
accessible table data and metadata, but this scope limitation becomes
attacker-
directed because the attacker can choose a reachable target location.
In the confirmed variant, if the caller supplies a custom `location` during
stage create and requests credential vending, Apache Polaris uses that location to
construct delegated storage credentials immediately. The stage-create path
itself neither runs the normal location validation nor the overlap checks
before those credentials are issued.
Closely related to that, the staged-create flow also accepts
`write.data.path` / `write.metadata.path` in the request properties and
feeds
those location overrides into the same effective table location set used for
credential vending. Those fields are secondary to the main custom-`location`
exploit, but they are still attacker-influenced location inputs that should
be
validated before any credentials are issued.
Severity ?
9.9 (Critical)
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/8tfsr8y7pgq6rdcvj… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Polaris |
Affected:
0 , < 1.4.1
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42809",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-04T16:30:34.510659Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:30:39.997Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2026-05-04T16:38:51.761Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/10"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Polaris",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "1.4.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eApache Polaris can issue broad temporary (\"vended\") storage credentials during\nstaged\ntable creation before the effective table location has been validated or\ndurably reserved. \u003cbr\u003eThose temporary credentials are meant to limit the scope\nof\naccessible table data and metadata, but this scope limitation becomes\nattacker-\ndirected because the attacker can choose a reachable target location.\n\u003cbr\u003e\u003cbr\u003e\nIn the confirmed variant, if the caller supplies a custom `location` during\nstage create and requests credential vending, Apache Polaris uses that location to\nconstruct delegated storage credentials immediately. The stage-create path\nitself neither runs the normal location validation nor the overlap checks\nbefore those credentials are issued.\n\u003cbr\u003e\u003cbr\u003e\nClosely related to that, the staged-create flow also accepts\n`write.data.path` / `write.metadata.path` in the request properties and\nfeeds\nthose location overrides into the same effective table location set used for\ncredential vending. Those fields are secondary to the main custom-`location`\nexploit, but they are still attacker-influenced location inputs that should\nbe\nvalidated before any credentials are issued.\u003c/span\u003e\u003cbr\u003e"
}
],
"value": "Apache Polaris can issue broad temporary (\"vended\") storage credentials during\nstaged\ntable creation before the effective table location has been validated or\ndurably reserved. \nThose temporary credentials are meant to limit the scope\nof\naccessible table data and metadata, but this scope limitation becomes\nattacker-\ndirected because the attacker can choose a reachable target location.\n\n\n\nIn the confirmed variant, if the caller supplies a custom `location` during\nstage create and requests credential vending, Apache Polaris uses that location to\nconstruct delegated storage credentials immediately. The stage-create path\nitself neither runs the normal location validation nor the overlap checks\nbefore those credentials are issued.\n\n\n\nClosely related to that, the staged-create flow also accepts\n`write.data.path` / `write.metadata.path` in the request properties and\nfeeds\nthose location overrides into the same effective table location set used for\ncredential vending. Those fields are secondary to the main custom-`location`\nexploit, but they are still attacker-influenced location inputs that should\nbe\nvalidated before any credentials are issued."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:36:15.856Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/8tfsr8y7pgq6rdcvjx95hkcr47td671r"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Polaris: staged table creation could vend storage credentials for unvalidated locations",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-42809",
"datePublished": "2026-05-04T16:22:48.527Z",
"dateReserved": "2026-04-30T13:55:36.799Z",
"dateUpdated": "2026-05-04T16:38:51.761Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42810 (GCVE-0-2026-42810)
Vulnerability from cvelistv5 – Published: 2026-05-04 16:48 – Updated: 2026-05-04 18:33
VLAI?
Title
Apache Polaris: could broaden vended S3 credentials through wildcard-bearing namespace or table names
Summary
Apache Polaris accepts literal `*` characters in namespace and table names. When it
later builds temporary S3 access policies for delegated table access, those
same characters appear to be reused unescaped in S3 IAM resource patterns
and
`s3:prefix` conditions.
In S3 IAM policy matching, `*` is treated as a wildcard rather than as
ordinary text. That means temporary credentials issued for one crafted table
can match the storage path of a different table.
In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary-
credential path on both MinIO and real AWS S3, credentials returned for
crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other
tables' S3 locations.
The confirmed behavior includes:
- reading another table's metadata control file ([Iceberg metadata JSON]);
- listing another table's exact S3 table prefix ([table prefix]);
- and, when write delegation was returned for the crafted table, creating
and
deleting an object under another table's exact S3 table prefix.
A control case using ordinary different names did not allow the same
cross-table access.
A least-privilege AWS S3 variant was also confirmed in which the attacker
principal had no Polaris permissions on the victim table and only the
minimal permissions required to create and use a crafted wildcard table
(namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that
setup, direct Polaris access to `foo.t1` remained forbidden, but the
attacker
could still create and load `*.*`, receive delegated S3 credentials, and use
those credentials to list, read, create, and delete objects under `foo.t1`.
In Iceberg, the metadata JSON file is a control file: it tells readers which
data files belong to the table, which snapshots exist, and which table
version
to read. So unauthorized access to it is already a meaningful
confidentiality
problem. The confirmed write-capable variant means the issue is not limited
to
disclosure.
Severity ?
9.9 (Critical)
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/gg3qq9sqg4hdjmprq… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Polaris |
Affected:
0 , < 1.4.1
(semver)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2026-05-04T17:37:04.202Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/11"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42810",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-04T18:32:53.859435Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T18:33:09.056Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Polaris",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "1.4.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eApache Polaris accepts literal `*` characters in namespace and table names. When it\nlater builds temporary S3 access policies for delegated table access, those\nsame characters appear to be reused unescaped in S3 IAM resource patterns\nand\n`s3:prefix` conditions.\n\u003cbr\u003e\u003cbr\u003e\nIn S3 IAM policy matching, `*` is treated as a wildcard rather than as\nordinary text. That means temporary credentials issued for one crafted table\ncan match the storage path of a different table.\n\u003cbr\u003e\u003cbr\u003e\nIn private testing against Polaris 1.4.0 using Polaris\u0027 AWS S3 temporary-\ncredential path on both MinIO and real AWS S3, credentials returned for\ncrafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other\ntables\u0027 S3 locations.\n\u003cbr\u003e\nThe confirmed behavior includes:\n\u003cbr\u003e\n- reading another table\u0027s metadata control file ([Iceberg metadata JSON]);\n\u003cbr\u003e- listing another table\u0027s exact S3 table prefix ([table prefix]);\n\u003cbr\u003e- and, when write delegation was returned for the crafted table, creating\nand\ndeleting an object under another table\u0027s exact S3 table prefix.\n\u003cbr\u003e\u003cbr\u003e\nA control case using ordinary different names did not allow the same\ncross-table access.\n\u003cbr\u003e\u003cbr\u003e\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eA least-privilege AWS S3 variant was also confirmed in which the attacker\nprincipal had no Polaris permissions on the victim table and only the\nminimal permissions required to create and use a crafted wildcard table\n(namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`).\u003c/span\u003e In that\nsetup, direct Polaris access to `foo.t1` remained forbidden, but the\nattacker\ncould still create and load `*.*`, receive delegated S3 credentials, and use\nthose credentials to list, read, create, and delete objects under `foo.t1`.\n\u003cbr\u003e\u003cbr\u003e\nIn Iceberg, the metadata JSON file is a control file: it tells readers which\ndata files belong to the table, which snapshots exist, and which table\nversion\nto read. So unauthorized access to it is already a meaningful\nconfidentiality\nproblem. The confirmed write-capable variant means the issue is not limited\nto\ndisclosure.\u003c/span\u003e\u003cbr\u003e"
}
],
"value": "Apache Polaris accepts literal `*` characters in namespace and table names. When it\nlater builds temporary S3 access policies for delegated table access, those\nsame characters appear to be reused unescaped in S3 IAM resource patterns\nand\n`s3:prefix` conditions.\n\n\n\nIn S3 IAM policy matching, `*` is treated as a wildcard rather than as\nordinary text. That means temporary credentials issued for one crafted table\ncan match the storage path of a different table.\n\n\n\nIn private testing against Polaris 1.4.0 using Polaris\u0027 AWS S3 temporary-\ncredential path on both MinIO and real AWS S3, credentials returned for\ncrafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other\ntables\u0027 S3 locations.\n\n\nThe confirmed behavior includes:\n\n\n- reading another table\u0027s metadata control file ([Iceberg metadata JSON]);\n\n- listing another table\u0027s exact S3 table prefix ([table prefix]);\n\n- and, when write delegation was returned for the crafted table, creating\nand\ndeleting an object under another table\u0027s exact S3 table prefix.\n\n\n\nA control case using ordinary different names did not allow the same\ncross-table access.\n\n\n\nA least-privilege AWS S3 variant was also confirmed in which the attacker\nprincipal had no Polaris permissions on the victim table and only the\nminimal permissions required to create and use a crafted wildcard table\n(namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that\nsetup, direct Polaris access to `foo.t1` remained forbidden, but the\nattacker\ncould still create and load `*.*`, receive delegated S3 credentials, and use\nthose credentials to list, read, create, and delete objects under `foo.t1`.\n\n\n\nIn Iceberg, the metadata JSON file is a control file: it tells readers which\ndata files belong to the table, which snapshots exist, and which table\nversion\nto read. So unauthorized access to it is already a meaningful\nconfidentiality\nproblem. The confirmed write-capable variant means the issue is not limited\nto\ndisclosure."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-116",
"description": "CWE-116 Improper Encoding or Escaping of Output",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:48:49.754Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/gg3qq9sqg4hdjmprqy46p40xmln61dm9"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Polaris: could broaden vended S3 credentials through wildcard-bearing namespace or table names",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-42810",
"datePublished": "2026-05-04T16:48:49.754Z",
"dateReserved": "2026-04-30T14:22:36.663Z",
"dateUpdated": "2026-05-04T18:33:09.056Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42811 (GCVE-0-2026-42811)
Vulnerability from cvelistv5 – Published: 2026-05-04 16:37 – Updated: 2026-05-04 19:48
VLAI?
Title
Apache Polaris: could broaden vended GCS credentials through unescaped identifier content in access-boundary CEL conditions
Summary
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.
Severity ?
9.9 (Critical)
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/hovn5hmkj9wj7v9cd… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Polaris |
Affected:
0 , < 1.4.1
(semver)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2026-05-04T16:38:55.378Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/12"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42811",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-04T19:48:24.896527Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T19:48:33.457Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Polaris",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "1.4.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eIn plain terms, Apache Polaris is supposed to issue short-lived GCS credentials\nthat\nonly work for one table\u0027s files, but a crafted namespace or table name can\ncause those credentials to work across the configured bucket instead.\n\u003cbr\u003e\u003cbr\u003eApache Polaris builds Google Cloud Storage downscoped credentials by creating a\nCredential Access Boundary (CAB) with CEL conditions that are intended to\nrestrict access to the requested table\u0027s storage path.\n\u003cbr\u003e\u003cbr\u003e\nThe relevant CEL string is built from the bucket name and the table path.\nThat\ntable path is derived from namespace and table identifiers. In current code,\nthat path appears to be inserted into the CEL expression without escaping.\n\u003cbr\u003e\u003cbr\u003e\nAs a result, a namespace or table identifier containing a single quote and\nother URI-safe CEL fragments can break out of the intended quoted string and\nchange the meaning of the CEL condition.\n\u003cbr\u003e\u003cbr\u003e\nIn private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated\nGCS\ncredentials whose CEL path restriction had effectively collapsed.\n\u003cbr\u003e\nThose delegated credentials could then:\n\u003cbr\u003e\n- list another table\u0027s object prefix;\n\u003cbr\u003e- read another table\u0027s metadata control file (Iceberg metadata JSON);\n\u003cbr\u003e- create and delete an object under another table\u0027s object prefix;\n\u003cbr\u003e- and also list, read, create, and delete objects under an unrelated\nexternal\nprefix in the same bucket that was not part of any table path.\n\u003cbr\u003e\u003cbr\u003e\nThat last point is important. The issue is not limited to \"another table\".\nIn\nthe confirmed setup, once Apache Polaris returned credentials for the crafted\ntable,\nthe path restriction inside the configured bucket was effectively gone.\n\nThe practical effect is that temporary credentials for one crafted table\ncan be\nbroader than the table Polaris was asked to authorize, and can become\neffectively bucket-wide within the configured bucket.\n\u003cbr\u003e\u003cbr\u003e\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eThe current GCS testing used a Polaris principal with broad catalog\nprivileges for setup. A separate least-privilege Polaris RBAC variant\nhas not yet been tested on GCS. However, the storage-credential\nbroadening behavior itself has been confirmed on GCS.\u003c/span\u003e\u003c/span\u003e\u003cbr\u003e"
}
],
"value": "In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials\nthat\nonly work for one table\u0027s files, but a crafted namespace or table name can\ncause those credentials to work across the configured bucket instead.\n\n\nApache Polaris builds Google Cloud Storage downscoped credentials by creating a\nCredential Access Boundary (CAB) with CEL conditions that are intended to\nrestrict access to the requested table\u0027s storage path.\n\n\n\nThe relevant CEL string is built from the bucket name and the table path.\nThat\ntable path is derived from namespace and table identifiers. In current code,\nthat path appears to be inserted into the CEL expression without escaping.\n\n\n\nAs a result, a namespace or table identifier containing a single quote and\nother URI-safe CEL fragments can break out of the intended quoted string and\nchange the meaning of the CEL condition.\n\n\n\nIn private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated\nGCS\ncredentials whose CEL path restriction had effectively collapsed.\n\n\nThose delegated credentials could then:\n\n\n- list another table\u0027s object prefix;\n\n- read another table\u0027s metadata control file (Iceberg metadata JSON);\n\n- create and delete an object under another table\u0027s object prefix;\n\n- and also list, read, create, and delete objects under an unrelated\nexternal\nprefix in the same bucket that was not part of any table path.\n\n\n\nThat last point is important. The issue is not limited to \"another table\".\nIn\nthe confirmed setup, once Apache Polaris returned credentials for the crafted\ntable,\nthe path restriction inside the configured bucket was effectively gone.\n\nThe practical effect is that temporary credentials for one crafted table\ncan be\nbroader than the table Polaris was asked to authorize, and can become\neffectively bucket-wide within the configured bucket.\n\n\n\nThe current GCS testing used a Polaris principal with broad catalog\nprivileges for setup. A separate least-privilege Polaris RBAC variant\nhas not yet been tested on GCS. However, the storage-credential\nbroadening behavior itself has been confirmed on GCS."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-917",
"description": "CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement (\u0027Expression Language Injection\u0027)",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:37:02.030Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/hovn5hmkj9wj7v9cd8sn67svg03klgvg"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Polaris: could broaden vended GCS credentials through unescaped identifier content in access-boundary CEL conditions",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-42811",
"datePublished": "2026-05-04T16:37:02.030Z",
"dateReserved": "2026-04-30T14:30:15.047Z",
"dateUpdated": "2026-05-04T19:48:33.457Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42809 (GCVE-0-2026-42809)
Vulnerability from cvelistv5 – Published: 2026-05-04 16:22 – Updated: 2026-05-04 16:38
VLAI?
Title
Apache Polaris: staged table creation could vend storage credentials for unvalidated locations
Summary
Apache Polaris can issue broad temporary ("vended") storage credentials during
staged
table creation before the effective table location has been validated or
durably reserved.
Those temporary credentials are meant to limit the scope
of
accessible table data and metadata, but this scope limitation becomes
attacker-
directed because the attacker can choose a reachable target location.
In the confirmed variant, if the caller supplies a custom `location` during
stage create and requests credential vending, Apache Polaris uses that location to
construct delegated storage credentials immediately. The stage-create path
itself neither runs the normal location validation nor the overlap checks
before those credentials are issued.
Closely related to that, the staged-create flow also accepts
`write.data.path` / `write.metadata.path` in the request properties and
feeds
those location overrides into the same effective table location set used for
credential vending. Those fields are secondary to the main custom-`location`
exploit, but they are still attacker-influenced location inputs that should
be
validated before any credentials are issued.
Severity ?
9.9 (Critical)
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/8tfsr8y7pgq6rdcvj… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Polaris |
Affected:
0 , < 1.4.1
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42809",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-04T16:30:34.510659Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:30:39.997Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2026-05-04T16:38:51.761Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/10"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Polaris",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "1.4.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eApache Polaris can issue broad temporary (\"vended\") storage credentials during\nstaged\ntable creation before the effective table location has been validated or\ndurably reserved. \u003cbr\u003eThose temporary credentials are meant to limit the scope\nof\naccessible table data and metadata, but this scope limitation becomes\nattacker-\ndirected because the attacker can choose a reachable target location.\n\u003cbr\u003e\u003cbr\u003e\nIn the confirmed variant, if the caller supplies a custom `location` during\nstage create and requests credential vending, Apache Polaris uses that location to\nconstruct delegated storage credentials immediately. The stage-create path\nitself neither runs the normal location validation nor the overlap checks\nbefore those credentials are issued.\n\u003cbr\u003e\u003cbr\u003e\nClosely related to that, the staged-create flow also accepts\n`write.data.path` / `write.metadata.path` in the request properties and\nfeeds\nthose location overrides into the same effective table location set used for\ncredential vending. Those fields are secondary to the main custom-`location`\nexploit, but they are still attacker-influenced location inputs that should\nbe\nvalidated before any credentials are issued.\u003c/span\u003e\u003cbr\u003e"
}
],
"value": "Apache Polaris can issue broad temporary (\"vended\") storage credentials during\nstaged\ntable creation before the effective table location has been validated or\ndurably reserved. \nThose temporary credentials are meant to limit the scope\nof\naccessible table data and metadata, but this scope limitation becomes\nattacker-\ndirected because the attacker can choose a reachable target location.\n\n\n\nIn the confirmed variant, if the caller supplies a custom `location` during\nstage create and requests credential vending, Apache Polaris uses that location to\nconstruct delegated storage credentials immediately. The stage-create path\nitself neither runs the normal location validation nor the overlap checks\nbefore those credentials are issued.\n\n\n\nClosely related to that, the staged-create flow also accepts\n`write.data.path` / `write.metadata.path` in the request properties and\nfeeds\nthose location overrides into the same effective table location set used for\ncredential vending. Those fields are secondary to the main custom-`location`\nexploit, but they are still attacker-influenced location inputs that should\nbe\nvalidated before any credentials are issued."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-862",
"description": "CWE-862 Missing Authorization",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:36:15.856Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/8tfsr8y7pgq6rdcvjx95hkcr47td671r"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Polaris: staged table creation could vend storage credentials for unvalidated locations",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-42809",
"datePublished": "2026-05-04T16:22:48.527Z",
"dateReserved": "2026-04-30T13:55:36.799Z",
"dateUpdated": "2026-05-04T16:38:51.761Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42812 (GCVE-0-2026-42812)
Vulnerability from cvelistv5 – Published: 2026-05-04 16:19 – Updated: 2026-05-04 16:38
VLAI?
Title
Apache Polaris: No protection on `write.metadata.path`
Summary
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.
Severity ?
9.9 (Critical)
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/wxd2wj3p0smvrk84m… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Polaris |
Affected:
0 , < 1.4.1
(semver)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42812",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-04T16:31:28.354079Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:31:33.619Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2026-05-04T16:38:57.660Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/13"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache Polaris",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "1.4.1",
"status": "affected",
"version": "0",
"versionType": "semver"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eIn Apache Iceberg, the table\u0027s metadata files are control files: they tell readers\nwhich data files belong to the table and which table version to read.\n\u003cbr\u003e\u003cbr\u003e\n`write.metadata.path` is an optional table property that tells Polaris\nwhere to\nwrite those metadata files. \u003cbr\u003eFor a table already registered in a\nPolaris-managed\ncatalog, changing only that property through an `ALTER TABLE`-style settings\nchange (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses\nthe commit-time branch that is supposed to revalidate storage locations.\n\nThe full persisted / credential-vending variant requires the affected\ncatalog\nto have `polaris.config.allow.unstructured.table.location=true`, with\n`allowedLocations` broad enough to include the attacker-chosen target.\n\u003cbr\u003e\u003cbr\u003e`allowedLocations` is the admin-configured allowlist of storage paths that\nthe\ncatalog is allowed to use. Public project materials suggest that this flag\nis a\nreal supported compatibility / layout mode, not just a contrived lab-only\nprerequisite.\n\u003cbr\u003e\nIn that configuration, a user who can change table settings can cause Apache Polaris\nitself to write new table metadata to an attacker-chosen reachable storage\nlocation before the intended location-validation branch runs.\n\nIf the later concrete-path validation also accepts that location, Polaris\npersists the resulting metadata path into stored table state. Later\ntable-load\nand credential APIs can then return temporary cloud-storage credentials for\nthe\nsame location without revalidating it. In plain terms, Polaris can later\nhand\nout temporary storage access for the same attacker-chosen area.\n\nThat attacker-chosen area does not need to be limited to the poisoned\ntable\u0027s\nown files. If it is a broader storage prefix, another table\u0027s prefix, or,\ndepending on configuration or provider behavior, even a bucket/container\nroot,\nthe resulting disclosure or corruption scope can extend to any data and\nmetadata Polaris can reach there.\n\u003cbr\u003e\u003cbr\u003e\nThe practical consequences are therefore similar to the staged-create\ncredential-vending issue already discussed: data and metadata reachable in\nthat\nstorage scope can be exposed and, if write-capable credentials are later\nissued, modified, corrupted, or removed. Even before that later credential\nstep, Polaris itself performs the metadata write to the unchecked location.\n\nSo the core issue is not only later credential vending. \u003cbr\u003e\u003cbr\u003eThe primary defect\nis\nthat Polaris skips its intended location checks before performing a\nsecurity-\nsensitive metadata write when only `write.metadata.path` changes.\n\u003cbr\u003e\u003cbr\u003e\nWhen `polaris.config.allow.unstructured.table.location=false`, current code\nreview suggests the later `updateTableLike(...)` validation usually rejects\nout-of-tree metadata locations before the unsafe path is persisted. That may\nreduce the persisted / credential-vending variant, but it does not prevent\nthe\nunderlying defect: Polaris still skips the intended pre-write location check\nwhen only `write.metadata.path` changes.\u003c/span\u003e\u003cbr\u003e"
}
],
"value": "In Apache Iceberg, the table\u0027s metadata files are control files: they tell readers\nwhich data files belong to the table and which table version to read.\n\n\n\n`write.metadata.path` is an optional table property that tells Polaris\nwhere to\nwrite those metadata files. \nFor a table already registered in a\nPolaris-managed\ncatalog, changing only that property through an `ALTER TABLE`-style settings\nchange (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses\nthe commit-time branch that is supposed to revalidate storage locations.\n\nThe full persisted / credential-vending variant requires the affected\ncatalog\nto have `polaris.config.allow.unstructured.table.location=true`, with\n`allowedLocations` broad enough to include the attacker-chosen target.\n\n\n`allowedLocations` is the admin-configured allowlist of storage paths that\nthe\ncatalog is allowed to use. Public project materials suggest that this flag\nis a\nreal supported compatibility / layout mode, not just a contrived lab-only\nprerequisite.\n\n\nIn that configuration, a user who can change table settings can cause Apache Polaris\nitself to write new table metadata to an attacker-chosen reachable storage\nlocation before the intended location-validation branch runs.\n\nIf the later concrete-path validation also accepts that location, Polaris\npersists the resulting metadata path into stored table state. Later\ntable-load\nand credential APIs can then return temporary cloud-storage credentials for\nthe\nsame location without revalidating it. In plain terms, Polaris can later\nhand\nout temporary storage access for the same attacker-chosen area.\n\nThat attacker-chosen area does not need to be limited to the poisoned\ntable\u0027s\nown files. If it is a broader storage prefix, another table\u0027s prefix, or,\ndepending on configuration or provider behavior, even a bucket/container\nroot,\nthe resulting disclosure or corruption scope can extend to any data and\nmetadata Polaris can reach there.\n\n\n\nThe practical consequences are therefore similar to the staged-create\ncredential-vending issue already discussed: data and metadata reachable in\nthat\nstorage scope can be exposed and, if write-capable credentials are later\nissued, modified, corrupted, or removed. Even before that later credential\nstep, 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\nis\nthat Polaris skips its intended location checks before performing a\nsecurity-\nsensitive metadata write when only `write.metadata.path` changes.\n\n\n\nWhen `polaris.config.allow.unstructured.table.location=false`, current code\nreview suggests the later `updateTableLike(...)` validation usually rejects\nout-of-tree metadata locations before the unsafe path is persisted. That may\nreduce the persisted / credential-vending variant, but it does not prevent\nthe\nunderlying defect: Polaris still skips the intended pre-write location check\nwhen only `write.metadata.path` changes."
}
],
"metrics": [
{
"other": {
"content": {
"text": "important"
},
"type": "Textual description of severity"
}
},
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-284",
"description": "CWE-284 Improper Access Control",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-20",
"description": "CWE-20 Improper Input Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-732",
"description": "CWE-732 Incorrect Permission Assignment for Critical Resource",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-04T16:19:55.828Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/wxd2wj3p0smvrk84msv317wg5tp3jtw9"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Apache Polaris: No protection on `write.metadata.path`",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-42812",
"datePublished": "2026-05-04T16:19:55.828Z",
"dateReserved": "2026-04-30T14:36:55.718Z",
"dateUpdated": "2026-05-04T16:38:57.660Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}