# CVE-2026-42809: Apache Polaris: staged table creation could vend storage credentials for unvalidated locations

> Attackers can obtain storage credentials for arbitrary locations during staged table creation, bypassing validation to access or modify unauthorized data.

- **Severity:** Critical 9.4 (`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`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 4 May 2026
- **Updated:** 4 May 2026
- **Also known as:** GHSA-8ggj-j522-h5qf

## What is CVE-2026-42809?

CVE-2026-42809 is a critical missing authorization vulnerability in Apache Polaris, published on 4 May 2026. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

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.

Weakness: CWE-862 (Missing Authorization), CWE-20 (Improper Input Validation)

## Which versions are affected by CVE-2026-42809?

2 open source packages ship an affected version, including org.apache.polaris:polaris-runtime-service. It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `org.apache.polaris:polaris-runtime-service` | Maven | All versions | 1.4.1 |
| `org.apache.polaris:polaris-runtime-service` | Maven | All versions | 1.4.1 |

Products: Apache Polaris.

## How do I fix CVE-2026-42809?

Upgrade org.apache.polaris:polaris-runtime-service to 1.4.1 or later.

## Is CVE-2026-42809 being exploited?

There is no known exploitation of CVE-2026-42809 in the wild and no public exploit code.

## Other vulnerabilities in Apache Polaris

- [CVE-2026-42810](https://insights.sbomify.com/CVE-2026-42810/): Apache Polaris: could broaden vended S3 credentials through wildcard-bearing namespace or table names (critical 9.4)
- [CVE-2026-42811](https://insights.sbomify.com/CVE-2026-42811/): Apache Polaris has an Improper Input Validation issue (critical 9.4)
- [CVE-2026-42812](https://insights.sbomify.com/CVE-2026-42812/): Apache Polaris: No protection on `write.metadata.path` (critical 9.4)
- [CVE-2026-64640](https://insights.sbomify.com/CVE-2026-64640/): Apache Polaris: register endpoint reads attacker-controlled storage location before allowed-locations validation (medium 5.3)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-42809 and fix it if it is affected.

What it is: CVE-2026-42809 is a critical missing authorization vulnerability in Apache Polaris, published on 4 May 2026. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-42809 in the wild and no public exploit code.

Affected packages and fixed versions:
- org.apache.polaris:polaris-runtime-service (Maven): affected all versions; fixed in 1.4.1
- org.apache.polaris:polaris-runtime-service (Maven): affected all versions; fixed in 1.4.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-42809/ (Markdown: https://insights.sbomify.com/CVE-2026-42809/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-42809
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-42809
- OSV: https://osv.dev/vulnerability/CVE-2026-42809

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-42809/
Summaries are generated and may contain mistakes; the official description above is the record.