Description

Apache Airflow's environment-variable secrets backend resolved a team-scoped Connection or Variable from the wrong team's scope. The guard meant to prevent this only ran when no team scope was supplied, and its pattern could not match a team name containing an underscore, which team names are allowed to contain. When the guard did not apply, the lookup fell through to an unconditional global read that resolved the stored `AIRFLOW_CONN__<TEAM>___<ID>` variable regardless of which team asked. In multi-team mode an authenticated user of one team could therefore have `POST /api/v2/connections/test` resolve another team's Connection and authenticate outward with that team's credentials; the endpoint uses the credentials rather than returning them. Exploitation requires `[core] multi_team` enabled, `[core] test_connection` set to `Enabled` (it ships `Disabled`), team-scoped secrets provisioned as environment variables in the API-server process, and knowledge of the encoded identifier. Redirecting the test at an attacker-controlled host is separately blocked. Users are advised to upgrade to apache-airflow 3.3.1 or later.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-08-12T16:17:15.223Z",
  "pubdate": "2026-08-12T16:17:15.223Z",
  "executiveSummary": "An improper authorization and scope validation vulnerability exists in Apache Airflow's environment-variable secrets backend.\nThe vulnerability allows an authenticated user belonging to one team to resolve and utilize team-scoped Connections or Variables belonging to a different team.\nThis flaw impacts multi-tenant deployments of Apache Airflow where the multi-team mode is enabled.\nThe risk includes unauthorized cross-tenant access and the potential misuse of sensitive credentials via specific testing functionality.\nAttacker capabilities are restricted to authenticated users who possess knowledge of the encoded target identifier and interact with specific API endpoints.\nExploitation strictly requires specific pre-conditions: [core] multi_team enabled, [core] test_connection set to Enabled, team-scoped secrets provisioned as environment variables in the API-server process, and knowledge of the encoded identifier.",
  "technicalDetails": "The root cause of the vulnerability stems from faulty input validation and scoping logic within the environment-variable secrets backend. Specifically, the security guard designed to prevent cross-team secret resolution only executed when no team scope was explicitly supplied.\nFurthermore, the pattern matching used by the guard was fundamentally flawed as it failed to evaluate team names containing underscores, which are natively permitted within team naming conventions.\nWhen the guard logic failed to evaluate or apply, the secrets backend execution flow fell through to an unconditional global read operation. This unconstrained lookup successfully resolved stored environment variables matching the pattern AIRFLOW_CONN__<TEAM>___<ID> regardless of the requesting team's actual authorization scope.\nIn multi-team deployment modes, an authenticated user of one team can exploit this behavior by interacting with the POST /api/v2/connections/test endpoint. By supplying specific parameters, the user can force the endpoint to resolve another team's Connection object.\nBecause the affected endpoint processes and consumes the resolved credentials rather than returning them directly in the response, the system authenticates outward utilizing the unauthorized victim team's credentials.\nNetwork exposure is constrained to the API server handling authenticated HTTP requests, and exploitation requires the attacker to possess prior knowledge of the encoded identifier representing the target team's secret.\nAlthough the vulnerability allows unauthorized credential utilization, direct redirection of the connection test payload at an attacker-controlled host is separately blocked by existing security controls."
}