EUVD-2026-55695
GHSA-6hj8-q7v2-996c
Severity by source
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
PR:L because valid team membership is required; S:C because exploitation crosses team isolation boundaries to expose a different team's credentials; no integrity or availability impact.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
3DescriptionCVE.org
The Azure Key Vault secrets backend in Apache Airflow's Microsoft Azure provider resolved a team-scoped Connection or Variable id through the team-agnostic lookup when the team-scoped lookup missed. In a deployment running multi-team mode with this backend, a caller in one team could resolve a secret belonging to another team by supplying an id that spells out that team's namespace, obtaining its credentials in full. No unusual configuration is required beyond enabling multi-team mode and using this backend. Users are advised to upgrade to apache-airflow-providers-microsoft-azure 14.1.0 or later, which refuses the team-agnostic fall-through for an id that could name a team namespace.
AnalysisAI
Cross-team credential disclosure in the Apache Airflow Microsoft Azure provider's Key Vault secrets backend allows any authenticated team member to read credentials belonging to a different team in multi-team deployments running versions prior to 14.1.0. The backend's team-scoped lookup falls through to a team-agnostic resolution when the scoped lookup misses, and an attacker in one team can deliberately trigger this by supplying a connection or variable ID whose normalized form encodes the target team's namespace prefix. No public exploit has been identified at time of analysis, but the attack primitive is directly derivable from the published patch diff, making this a credible insider-privilege escalation risk for any organization using this backend in multi-team mode.
Technical ContextAI
The vulnerability resides in providers/microsoft/azure/src/airflow/providers/microsoft/azure/secrets/key_vault.py within the AzureKeyVaultBackend class. In multi-team Airflow deployments, secrets in Azure Key Vault are namespaced by team using a dedicated separator (TEAM_SEP, '--'). The flawed method _is_team_specific_accessed_as_global() only blocked team-agnostic callers (team_name=None) from accessing team-scoped secrets, but did not prevent a legitimately scoped caller from supplying a connection or variable ID whose normalized form - after build_path() maps underscores to the separator - encodes another team's namespace. This caused the team-scoped lookup to resolve to the target team's Key Vault secret. A further subtlety: because build_path normalizes '_' to the separator, an ID like 'teama__mydb' manufactures the TEAM_SEP without visibly containing it, bypassing naive string checks. CWE-639 (Authorization Bypass Through User-Controlled Key) applies directly: the secret lookup key is caller-supplied and was not validated against cross-namespace boundaries prior to resolution. The fix introduces _names_a_team_namespace(), which refuses any secret ID whose normalized form contains TEAM_SEP, blocking the ambiguous reference in both team-scoped and team-agnostic lookup paths. Affected CPE: cpe:2.3:a:apache_software_foundation:apache_airflow_microsoft_azure_provider:*:*:*:*:*:*:*:*.
RemediationAI
Upgrade apache-airflow-providers-microsoft-azure to version 14.1.0 or later, which is the vendor-confirmed fix version per the advisory at https://lists.apache.org/thread/dtkk6vtfoj1y4zjyd6s3mzg0v5g9yg0p and the upstream patches at https://github.com/apache/airflow/pull/70876 and https://github.com/apache/airflow/pull/70899. If an immediate upgrade is not feasible, the most targeted compensating control is to restrict which connection and variable IDs are permitted at the Airflow application layer - specifically blocking any ID that contains the team separator string ('--') or its underscore equivalent ('__'), which would prevent attackers from crafting namespace-crossing IDs. The trade-off is that this restriction may break legitimate IDs containing those substrings. A second option is to temporarily disable the Azure Key Vault secrets backend and substitute a non-team-namespaced secrets backend, eliminating the vulnerability entirely at the cost of losing Key Vault integration. Disabling multi-team mode is a more disruptive fallback that removes the attack surface but collapses team isolation for the entire deployment. Rotating credentials for all teams after patching is advised, since it is not possible to determine retrospectively whether cross-team lookups were attempted.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today