In prior versions of the Apache Airflow Amazon provider, secrets stored in AWS Secrets Manager and SSM Parameter Store could be accessed by an attacker who had privileges but no team context. The provider’s team‑scoping logic used a slash to separate team names in a conn_id (for example, "my_team/conn"). If the caller lacked a team context, the slash was interpreted literally, causing the same path to be resolved for another team’s secret. By supplying a crafted conn_id with a different team prefix, a privileged user could read a secret belonging to another team. The bug existed only for the experimental multi‑tenant teams feature. Once identified, the issue was fixed in version 9.28.0 by changing the separator to a double dash and rejecting team‑shaped conn_ids when no team context is available. Consequently, the primary impact is the potential exfiltration of confidential secrets that were meant to be team‑restricted.

Affected are installations of the Apache Airflow Amazon provider older than version 9.28.0. The flaw is limited to the experimental multi‑tenant teams feature, so typical single‑team configurations are not impacted. Users of Airflow versions that still reference the old conn_id parsing logic should consider their deployment vulnerable.

The CVSS score of 5.3 indicates moderate severity. EPSS data is unavailable and the vulnerability is not listed in the CISA KEV catalog, implying it is not a widely exploited public exploit. The exploit requires a privileged caller that can construct a custom conn_id and no team context. In practice, this means an attacker would need higher‑level access to Airflow (or the underlying IAM role) to leverage the flaw. Nevertheless, the availability of a path that breaches team boundaries represents a non‑negligible risk, especially in environments that rely on multi‑tenant isolation.