Description

The Google Cloud Secret Manager secrets backend in Apache Airflow's Google provider never applied the team scope when resolving Connections and Variables: the caller's `team_name` was accepted by the backend but dropped at the internal call boundary, so every lookup resolved against the team-agnostic secret name. In a deployment running multi-team mode with this backend, a task or Dag belonging to one team resolved another team's Connection or Variable, 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-google 22.3.0 or later, which builds and applies the team-scoped secret name.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-12T11:17:10.063Z",
  "pubdate": "2026-08-12T11:17:10.063Z",
  "executiveSummary": "A scoping enforcement vulnerability exists within the Google Cloud Secret Manager secrets backend in the Apache Airflow Google provider. The vulnerability type is an authorization bypass resulting from missing scope enforcement during secret resolution. The impact includes unauthorized access to sensitive credentials, allowing a task or DAG belonging to one team to resolve another team's Connection or Variable, thereby obtaining its credentials in full. The affected system is Apache Airflow running in multi-team mode utilizing the Google Cloud Secret Manager secrets backend within the apache-airflow-providers-google package prior to version 22.3.0. The risk implications are severe in multi-tenant environments, as isolation boundaries between different teams are compromised. Attacker capabilities include the ability to read arbitrary secrets across team boundaries if they execute malicious or unauthorized tasks or DAGs within the deployment. Exploitation requirements are minimal, needing only the activation of multi-team mode and the use of the vulnerable Google Cloud Secret Manager secrets backend, with no unusual configuration required.",
  "technicalDetails": "The root cause of the vulnerability resides in the internal call boundary of the Google Cloud Secret Manager secrets backend within the Apache Airflow Google provider. Specifically, while the secrets backend accepted the caller's team_name parameter, it failed to apply this team scope when resolving Connections and Variables. Instead, the team_name was dropped at the internal call boundary, causing every lookup to resolve against the team-agnostic secret name rather than the intended team-scoped identifier.\nThe vulnerable component is the Google Cloud Secret Manager secrets backend implementation inside apache-airflow-providers-google versions prior to 22.3.0. The authentication and privilege requirements depend on the context of the running Airflow tasks or DAGs within a multi-team deployment; any user or workload capable of executing a task or DAG under one team can trigger the lookup mechanism.\nThe step-by-step attack flow proceeds as follows: First, a deployment of Apache Airflow is configured in multi-team mode utilizing the Google Cloud Secret Manager secrets backend. Second, an authenticated user or tenant deploys a task or DAG belonging to a specific team (Team A). Third, the task attempts to resolve a Connection or Variable. Fourth, the secrets backend accepts the caller's team_name context but drops it internally during the lookup process. Fifth, the backend queries the Google Cloud Secret Manager using a team-agnostic secret name instead of the scoped name for Team A. Sixth, this misrouted query results in the retrieval of secrets belonging to a different team (Team B). Finally, the executing task obtains full access to the cross-team credentials, resulting in a complete breach of multi-tenant isolation.\nThe post-exploitation impact includes unauthorized credential disclosure, lateral movement across team boundaries, and potential compromise of external systems secured by the leaked Connections and Variables."
}