Airflow HashiCorp Provider EUVD-2026-86475

Requires a MULTI-TEAM Apache Airflow deployment configured with the HashiCorp Vault secrets backend (VaultBackend); single-team deployments are not affected because no cross-team boundary exists. The attacker must be an authenticated Dag author scoped to at least one team and able to submit Dag code that requests an Airflow Variable via the Execution API Variables route. Exploitation depends on supplying a Variable key containing a path separator so that, after the team-scoped lookup misses, the backend falls back to a team-agnostic path concatenated from the unvalidated key. Impact is limited to read-only disclosure of another team's secrets (no write/integrity or availability effect). Deployments not using the Vault backend, or not using multi-team scoping, are outside the vulnerable configuration.

No CVSS score or vector was provided by the vendor (CVSS: N/A), so raw-signal comparison is limited. There is no EPSS score, no CISA KEV listing, and no public exploit code - status: no public exploit identified at time of analysis. My independent assessment (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, ~6.8 MEDIUM) reflects a network-reachable, low-privilege, read-only cross-tenant secret disclosure. The real-world risk is materially constrained by preconditions: it only affects MULTI-TEAM Airflow deployments that use the HashiCorp Vault secrets backend - single-team deployments have no cross-team boundary and are explicitly unaffected. The attacker must already be an authenticated Dag author scoped to one team (PR:L), so this is an insider/tenant-boundary escalation, not a mass-exploitable perimeter bug. This is one of a documented family of identical-class flaws (CVE-2026-86465, CVE-2026-68870/68871/68872 in the Akeyless, Azure Key Vault, Yandex Lockbox and Amazon backends), which raises confidence the root cause is real and systematically understood, but the absence of EPSS/KEV/POC and the narrow deployment prerequisite make this a moderate-priority patch for affected multi-team operators rather than an emergency. Note the input Tags include 'Microsoft', which is a wrong-vendor artifact - the affected software is Apache Airflow's HashiCorp provider, unrelated to Microsoft.

In a multi-team Airflow deployment using the Vault secrets backend, a Dag author scoped to Team A writes ordinary Dag code that requests an Airflow Variable whose key contains a path separator (e.g. crafted to point at Team B's secret path). The team-scoped lookup misses, the backend falls back to a team-agnostic path concatenated from the unvalidated key, and Team B's secret is returned to Team A's Dag via the Execution API Variables route. No public exploit code is known, but the technique requires no special tooling beyond normal Dag authoring.