GPU VulnDB

Database/Control plane, storage & DevOps

Airflow HashiCorp provider: path-shaped Variable key crosses team scope in the Vault secrets backend

CVSS 6.5CVE-2026-97636Control plane, storage & DevOpscurated

Impact

In a multi-team Airflow deployment, the Vault secrets backend falls back to a team-agnostic path built from an unvalidated key after the team-scoped lookup misses. A Dag author scoped to one team can therefore supply a Variable key containing a path separator and read a secret belonging to another team, and the Execution API Variables route accepts path-shaped keys, so ordinary Dag code reaches it. On a shared GPU cluster where Airflow orchestrates training and data pipelines, the secrets in question are typically registry credentials, cloud keys and storage tokens, so one tenant's pipeline author can obtain another tenant's credentials. Single-team deployments have no boundary to cross and are unaffected. Apache notes this is the same class as CVE-2026-86465, CVE-2026-68870, CVE-2026-68871 and CVE-2026-68872 in the Akeyless, Azure Key Vault, Yandex Lockbox and Amazon backends; those ids are not in this batch and are not consolidated here.

Who can reach it

An authenticated Airflow user who can author or edit a Dag in one team, in a multi-team deployment using the HashiCorp Vault secrets backend. No cluster or Vault credentials needed beyond that.

What to do

Upgrade apache-airflow-providers-hashicorp to 4.8.0 or later and restart the scheduler, workers and API server so the new provider loads; no node drain or reboot. Rotate any Vault secrets a cross-team Dag author could have read, since reads leave little trace. Single-team deployments can patch on the normal cycle.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.