EUVD-2026-55701
GHSA-984p-rgj2-h89x
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network vector with low-privilege team membership required; scope changes because exploitation crosses team namespace boundaries to expose another team's secrets; no integrity or availability impact applies.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
3DescriptionCVE.org
The AWS Systems Manager Parameter Store and Secrets Manager backends in Apache Airflow's Amazon 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 either 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 one of these backends. Users are advised to upgrade to apache-airflow-providers-amazon 9.34.0 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 Amazon Provider (all versions before 9.34.0) allows an authenticated Airflow team member to read Connections, Variables, or Configuration secrets belonging to a different team in a multi-team deployment. By crafting a lookup ID that embeds the '--' team namespace separator, an attacker causes the provider's team-scoped lookup to miss and the pre-patch team-agnostic fallback to resolve the target team's AWS Secrets Manager or SSM Parameter Store secret in plaintext. No public exploit has been identified at time of analysis and the CVE is not listed in CISA KEV, but the exploit technique is mechanically straightforward given the documented '--' naming convention.
Technical ContextAI
Apache Airflow's Amazon provider (CPE: cpe:2.3:a:apache_software_foundation:apache_airflow_amazon_provider) supports storing Airflow Connections and Variables in AWS Secrets Manager and AWS Systems Manager Parameter Store. In multi-team mode, secrets are namespaced using the pattern '<team_name>--<secret_id>', where '--' (TEAM_SEP) delimits the team prefix from the secret base ID. CWE-639 (Authorization Bypass Through User-Controlled Key) is the root cause: the caller supplies the Connection or Variable ID, and the provider constructs the team-scoped path from that caller-controlled value. When an attacker supplies an ID that itself contains '--' (e.g., 'targetteam--targetsecret'), the constructed scoped path does not exist in the caller's own namespace, the team-scoped lookup returns nothing, and the pre-patch code fell back to a team-agnostic lookup that resolved the full crafted string against the backend, returning the target team's secret. The fix in PR #70878 adds a _names_a_team_namespace() guard to both secrets_manager.py and systems_manager.py that refuses any Connection, Variable, or Configuration ID containing '--' before any lookup is attempted, eliminating the ambiguous path construction across all getter methods.
RemediationAI
Upgrade to apache-airflow-providers-amazon 9.34.0 or later, as confirmed by the Apache security advisory at https://lists.apache.org/thread/9nd31g40rd2zpgwwymskvjpfq1xnmllg and the upstream fix at https://github.com/apache/airflow/pull/70878. Version 9.34.0 introduces the _names_a_team_namespace() guard in both affected backends, refusing any ID containing '--' across connection, variable, and configuration getters, which eliminates the cross-namespace fallback path entirely. If immediate upgrade is not feasible, a targeted compensating control is to enforce input validation that rejects Connection and Variable IDs containing '--' at the Airflow API or UI layer before the secrets backend is consulted; this requires custom middleware or policy enforcement and must cover all ingestion paths to be effective. A more disruptive but comprehensive interim measure is to temporarily switch from the AWS secrets backend to environment-variable-based secret storage, which removes the vulnerable code path entirely at the cost of disrupting multi-team secret isolation architecture and requiring manual secret migration. Disabling multi-team mode entirely also eliminates the vulnerability but removes the tenant-isolation capability the feature provides.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today