CVE-2026-68872

CVE-2026-68872 is a team isolation bypass in Apache Airflow's Amazon backend (SSM and Secrets Manager). When multi-team mode is enabled, secrets are supposed to be resolved within a team's namespace only. The vulnerability: a team-scoped lookup that fails to find a secret automatically falls back to team-agnostic resolution. An attacker who knows or can guess a team namespace naming convention can craft a secret ID that survives the team-scoped check but resolves in the less restrictive fallback path — reading secrets from other teams. The fix in 9.34.0 adds a guard that refuses the team-agnostic fallback when the secret ID could plausibly name a team namespace. This closes the immediate bypass but leaves the underlying design problem intact: the fallback logic still exists, still compiled, still callable. The guard is a runtime string check, not a code deletion. Future maintainers adding new backends or refactoring the lookup chain may not realize this guard exists — and if the guard is ever removed during refactoring, the vulnerability reapears. What matters for defenders: First, upgrade to 9.34.0 immediately — this is exploitable in multi-team mode. Second, audit any deployment that intentionally used team-agnostic fallbacks for legitimately unnamespaced resources; the 9.34.0 fix breaks that pattern and those secrets will stop resolving. Third, the severity rating of 6.5 understates the risk: once inside any team, an attacker can cascade to every other team's secrets in a single malformed ID — there is no human-in-the-loop, no confirmation step, no audit flag marking which resolution path was taken. The deeper concern: this is the third known instance of this vulnerability class in Airflow's provider ecosystem — fallback lookup chains that predate security boundaries, retrofitted with guards rather than removed. The Amazon backend was patched. The question is whether other backends (GCP, Azure, HashiCorp Vault) carry the same fallback pattern and have not been audited. The pattern-matching heuristic that gates the fallback — "does this ID look like a team namespace?" — is inherently brittle. It assumes attackers don't know namespace conventions, which is a weak assumption if those conventions are documented, inferable from error messages, or simply trial-and-errorable. The complete fix is architectural, not patchable: the fallback path should be eliminated for any ID that could plausibly be team-scoped, or team IDs should be structurally distinguishable from non-team IDs at the type level so the lookup chain cannot accidentally route them to a lower-privilege resolver. Until then, treat this as a recurring vulnerability class and audit your providers.

Reviewed through automated stages and approved by a human before publication.