GHSA-8GGJ-J522-H5QF
Vulnerability from github – Published: 2026-05-04 18:30 – Updated: 2026-05-08 17:56Apache 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.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.polaris:polaris-runtime-service"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42809"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T17:56:10Z",
"nvd_published_at": "2026-05-04T17:16:26Z",
"severity": "CRITICAL"
},
"details": "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.\n\nIn 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.\n\nClosely related to that, the staged-create flow also accepts `write.data.path` / `write.metadata.path` in the request properties and\nfeeds 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.",
"id": "GHSA-8ggj-j522-h5qf",
"modified": "2026-05-08T17:56:10Z",
"published": "2026-05-04T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42809"
},
{
"type": "WEB",
"url": "https://github.com/apache/polaris/commit/c98d610bc8f7ee237b272e01814391838dd6abf9"
},
{
"type": "WEB",
"url": "https://github.com/apache/polaris"
},
{
"type": "WEB",
"url": "https://github.com/apache/polaris/releases/tag/apache-polaris-1.4.1"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/8tfsr8y7pgq6rdcvjx95hkcr47td671r"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"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",
"type": "CVSS_V4"
}
],
"summary": "Apache Polaris has an Improper Input Validation Issue"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.