EUVD-2026-55698
GHSA-qmrf-jrpr-rjx6
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network-delivered via Airflow API, low-privilege team membership required, scope changes across team boundary, high confidentiality loss; no integrity or availability impact.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
3DescriptionCVE.org
The Yandex Lockbox secrets backend in Apache Airflow's Yandex 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-yandex 4.5.1 or later, which refuses the team-agnostic fall-through for an id that could name a team namespace.
AnalysisAI
Cross-team secret disclosure in Apache Airflow's Yandex Lockbox secrets backend exposes one team's credentials to members of a different team in multi-team deployments. Any authenticated Airflow user belonging to any team can retrieve connections or variables owned by another team by supplying a secret ID that embeds the target team's namespace separator sequence. The flaw requires only that multi-team mode and the Yandex Lockbox backend are active - both standard, documented configurations - and yields full plaintext credential exposure. No public exploit or CISA KEV listing exists at time of analysis.
Technical ContextAI
Apache Airflow's multi-team isolation model scopes Connections and Variables to a team namespace using a separator token (the double-slash sequence, controlled by TEAM_SEP_MULTIPLIER). The Yandex Lockbox secrets backend (airflow/providers/yandex/secrets/lockbox.py) implements a two-phase lookup: first a team-scoped lookup, then a team-agnostic fallthrough. The pre-fix guard method _is_team_specific_accessed_as_global only blocked the fallthrough when the caller had no team context (team_name is None); it did not block a cross-team call where the supplied ID itself spelled out another team's namespace. CWE-639 (Authorization Bypass Through User-Controlled Key) is the root cause: the secret identifier is attacker-controlled, and by embedding the team separator into the ID the attacker constructs a key that resolves to a different team's secret in the Lockbox name hierarchy. The fix replaces the guard with _names_a_team_namespace, which refuses any ID containing the team separator unconditionally - for both team-scoped and team-agnostic lookups - because such IDs are structurally ambiguous and cannot be safely attributed to any single team.
RemediationAI
Upgrade apache-airflow-providers-yandex to version 4.5.1 or later, which is confirmed as the vendor-released fix per the Apache advisory (https://lists.apache.org/thread/jlj9tv085txk4t0j029mvh43mz89o63c) and PR #70877. This version introduces _names_a_team_namespace, refusing any lookup where the supplied ID contains the team separator, closing both the team-agnostic fallthrough and the ambiguous team-scoped path. If an immediate upgrade is not possible, the most effective compensating control is to disable multi-team mode or switch the secrets backend away from Yandex Lockbox until patching is complete; note that disabling multi-team mode collapses all team isolation and may expose other separation concerns. Alternatively, restrict Airflow UI and API access to only the minimum set of trusted users per team, reducing the population of potential abusers, though this does not eliminate the vulnerability. Audit Lockbox access logs for any secret resolutions where the looked-up name contains the double-slash separator sequence used as the team namespace delimiter, as these would be indicators of exploitation.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today